Repository navigation
fix(catalog-reader): read Catalogs without SQLite locks - #59
Merged
Merged
Conversation
A read transaction held while Capture One saves makes Capture One drop that save and every later change to the document, even at close. On 16.8.5.30 a read held across the save tick stalled it in 8 of 8 trials, and polling `catalog collections` twice a second stalled it in 1 of 6. The same 70-second hold through immutable=1 stalled it in 0 of 3. Each observation now opens a fresh immutable connection and keeps its result only when no rollback journal exists and the change counter, size and mtime match before and after; otherwise it retries until the 10-second deadline. WAL Catalogs fail closed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The catalog suite's lost albums and clones came from its own polling reads, not from Capture One's uptime. Tests/stored_read.py gives Python readers the same lock-free, retried read as c1; the live suites and probe scripts use it, the failure snapshot goes through `c1 catalog snapshot`, and stored_read_test rejects any other read-only SQLite connection. Drop the refuted uptime evidence and advice. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Why
Capture One drops a save, and every later change to the document, when another process holds a SQLite read lock as the save commits. The catalog suite polled stored reads during exactly that window, which is what lost its albums and clones (#43). Photographers lose work in the same way: production edits and
catalogreads also went through the locking reader.What changed
CatalogReaderopens a freshimmutable=1connection per attempt and keeps a result only when no-journalexists and the change counter, size and mtime match before and after. Otherwise it retries until the 10-second deadline.Tests/stored_read.pydoes the same for Python. Live suites and probe scripts use it, andstored_read_test.pyrejects any other read-only SQLite connection.Scope
Tradeoffs
Blast Radius
The change touches every stored read:
catalogcommands, the read workflow, and the All Images lookup in Catalog edits. WAL databases now fail closed. Capture One Catalogs and Sessions use rollback-journal mode.Verification
immutable=1lost it in 0 of 3. Polling reads with the old c1 lost it in 1 of 6 trials, and with this c1 in 0 of 12.make qualify QUALIFY_SUITES=catalog QUALIFY_DOCUMENT_KINDS=catalogpassed 5 consecutive package-layout runs and 2 unpackaged runs.make checkpasses. The new tests fail with the stamp check removed, with the journal check removed, and with a locking reader. The snapshot reservation was later moved out of the retry loop, and that change is verified offline only.🤖 Generated with Claude Code