M6 [P1]: WORM/ledger append is non-atomic — serialize the hash-chain writes #245
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: KofTwentyTwo/nuncio#245
Reference in new issue
Block a user
DatabaseEngine::save_filter_execution_log(db.rs:1683-1734) andappend_worm_audit_record(db.rs:1945-1993) read the latest hash then insert with NO transaction/lock. Concurrent appends can read the same prev-hash and fork/corrupt the tamper-evident chain. Goal: make each append atomic (single transaction with the read+insert, or a serializing mutex around the chain-append path) so the hash chain cannot be corrupted under concurrency; add a concurrent-append regression test.Source: full-tree audit 2026-07-30 (scratchpad/audit/AUDIT-SUMMARY.md). Follow docs/STORY-WORKFLOW.md: engine+proto(if surface)+CLI+offline E2E, mock-only tests, no fabricated data, comment convention, PR to dev, PO reviews before close.
Delivered via PR #266 (squash-merged to dev). save_filter_execution_log and append_worm_audit_record now wrap SELECT-latest-hash + INSERT in a single BEGIN IMMEDIATE transaction, so concurrent appends serialize on the SQLite write lock and can't fork the tamper-evident chain (correct across the whole pool, not just one task set). Concurrency regression tests (20 concurrent appends → valid contiguous chain, both WORM + ledger) — proven genuine by reverting the fix and confirming 5/5 failures. Reconciles #164.