bug: a query can see part of a committed transaction #554

Affected versions: WriteTransaction::commit from v0.5.0 (be5db49), execute("(transact ...)") and execute("(retract ...)") from v0.6.0 (21b555a), through v2.0.5, and v3.

Bug

WriteTransaction::commit writes the WAL entry, then appends the transaction's facts to the pending store one load_fact call at a time (src/db.rs:1594–1597 on v3). Each call takes and releases the pending store's write lock. A query on another thread can run between two calls and see part of the committed transaction.

Minigraf::execute's transact and retract path does the same (src/db.rs:759–761 on v3), since v0.6.0 moved it to WAL-first ordering. (An earlier version of this issue said execute was atomic; it is not. transact_batch is only used below the facade.)

Reproducer

tests/snapshot_atomicity_test.rs on branch test/snapshot-atomicity-repro (dc7fa7a):

• write_transaction_commit_is_seen_whole_in_memory
• write_transaction_commit_is_seen_whole_on_file

A writer commits 500-fact WriteTransactions in a loop. A reader counts the facts and expects a multiple of 500. Within seconds it saw 49 and 9 facts on v3, and 3 and 4 on main.

cargo test --test snapshot_atomicity_test write_transaction -- --ignored

Fix

Append a committed transaction's facts under one write lock: a batch append like transact_batch, also used by WAL replay. #473 spec §4.1 (#543) requires this. It is also needed on v2.x.

Workaround

Do not query from another thread while another thread writes.

Status

v3: PR #556 (FactStorage::load_facts, one write lock per transaction; execute reproducers added). v2.x backport to follow.