Skip to content

feat(change-stream): generic garbage collector - #747

Open
aldy505 wants to merge 1 commit into
aldy505/feat/change-stream/sqlite-garbage-collectorfrom
aldy505/feat/change-stream/generic-garbage-collector
Open

aldy505 wants to merge 1 commit into
aldy505/feat/change-stream/sqlite-garbage-collectorfrom
aldy505/feat/change-stream/generic-garbage-collector

Conversation

@aldy505

@aldy505 aldy505 commented Nov 1, 2026

Copy link
Copy Markdown
Collaborator

Stack created with GitHub Stacks CLI • Give Feedback 💬

@aldy505
aldy505 requested a review from a team as a code owner November 1, 2026 14:27
@github-actions

github-actions Bot commented Nov 1, 2026

Copy link
Copy Markdown

Changelog Preview

This PR lands in these workspaces:

  • objectstore-server: CalVer
📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).


New Features

  • Generic garbage collector by aldy505 in #747

🤖 This preview updates automatically when you update the PR.

@aldy505
aldy505 added this pull request to stack #749 November 1, 2026 14:28
@codecov

codecov Bot commented Nov 1, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 97.89474% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.59%. Comparing base (1fe4d59) to head (aaad2fb).

Files with missing lines Patch % Lines
objectstore-service/src/change_stream/gc.rs 97.89% 2 Missing ⚠️
Additional details and impacted files
@@                                   Coverage Diff                                   @@
##           aldy505/feat/change-stream/sqlite-garbage-collector     #747      +/-   ##
=======================================================================================
+ Coverage                                                91.57%   91.59%   +0.01%     
=======================================================================================
  Files                                                      117      118       +1     
  Lines                                                    22383    22478      +95     
=======================================================================================
+ Hits                                                     20498    20588      +90     
- Misses                                                    1885     1890       +5     
Components Coverage Δ
Rust Backend 94.73% <97.89%> (+0.01%) ⬆️
Rust Client 84.41% <ø> (ø)
Python Client 93.88% <ø> (ø)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit aaad2fb. Configure here.


async fn commit_delete(&self, id: &ObjectId) {
self.storage.remove(id).await
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete can drop in-flight writes

Medium Severity

commit_delete removes the GC index entry with no sequencing against an in-flight write. A concurrent begin_write can record a deadline, then commit_delete can drop it, after which the write still succeeds. Because commit_write is a no-op, that object is never re-indexed and will not be collected.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit aaad2fb. Configure here.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this behavior is acceptable. Should we guard the begin_write expiry time to be more than some seconds?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant