[BUG](sysdb): Take write lock in delete_collection - #7522
Open
vishnujayvel wants to merge 1 commit into
Open
Conversation
delete_collection opened a deferred transaction, so SQLite did not acquire the write lock until the first write. A concurrent create and delete on the same collection name could therefore interleave and lose an update. create_collection already calls begin_immediate for exactly this reason; do the same here. Closes chroma-core#7375
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SqliteSysDb::delete_collectionopens its transaction withbegin(), which starts a deferred SQLite transaction — the write lock isn't taken until the first actual write. In that window another connection can open its own transaction on the same collection name and interleave, so a concurrent create/delete pair can both report success and lose an update.create_collectionalready guards against this by followingbegin()withbegin_immediate();delete_collectiondid not. Credit to @roli-lpci for reporting #7375 and pinning down that asymmetry — the diagnosis in the issue is exactly right.This adds the same
begin_immediate()call so the write lock is acquired up front and the two paths behave consistently.Verified with
cargo test -p chroma-sysdb sqlite::(15 passed),cargo fmt --check, andcargo clippy -p chroma-sysdb --lib -- -D warnings, on a branch merged with currentmain.Closes #7375
🤖 Generated with Claude Code