[kriszyp]

⊙ Problem

On LMDB, refreshing an invalidated cached record from its source drops its transaction-log entry: the log still says invalidate (or omits delete when the source misses). History and LMDB replication read that log.

Also on LMDB, a source write to the key being resolved gets overwritten by the fill or leaves a stray index entry. RocksDB has neither problem.

🤔 Is this the right scope?

The task asked whether a duplicate ifVersion check could go. That check caused the lost log entries, and removing it exposed the same-key case, so this PR fixes both, on LMDB only. RocksDB's fill path is unchanged: rocksdb-js never read the dropped option.

💡 Solution

• Fills no longer put their own ifVersion on each store write (recordUpdater put options); LMDB's transaction-level condition covers them.
• On LMDB, a fill yields to any earlier same-key write in its transaction (admission check), such as a source put, update, invalidate or publish. An update() that changes nothing no longer counts.
• On LMDB, an invalidated record keeps its old local time only while its log entry exists to be replaced (timestamp choice).

⚖️ Alternatives

• Drop ifVersion only from the log writes: the primary-row check still let the fill's index and log writes land over the source's write.
• Run the yield on both engines: RocksDB already sees those writes, and would also yield to a source update() not yet saved.
• Make lmdb-js ignore ifVersion on unversioned stores: a dependency contract change for Harper's wrong token.

🤔 Should the source's own write win over its fill?

On LMDB, yes: the reader gets the source's value and the row keeps the source's write. A source update() to an invalidated key leaves an invalidated stub the next read refills, as on main but without the stray index entry. RocksDB applies that update on top of the fill, as on main.

🔧 Changes

• resources/RecordEncoder.ts: recordUpdater drops ifVersion from the primary put and both log puts. On LMDB it keeps the invalidated record's local time only when the log entry to replace exists.
• resources/Table.ts: ⚠️ Look hardest: on LMDB only, the fill's commit handler skips when followsAppliedWrite finds an earlier same-key write that was not skipped. The stale TODO is gone. The Fix sourcedFrom cache-fill conflict convergence #2065 version comparison is unchanged.
• resources/LMDBTransaction.ts: removeWrite goes through detachWrite, which also unlinks the write from its key's chain. Only an LMDB update() that changes nothing is removed this way, so a later write to that key in the same transaction no longer treats it as a predecessor.
• resources/DESIGN.md: who enforces a fill's condition on each engine, the LMDB-only yield, and the local-time rule.

✅ Verification

• New unitTests/resources/sourceFillConditionalWrite.test.js runs on both engines (15 LMDB, 13 RocksDB). Against a merge-base build, all 13 RocksDB cases pass and 9 LMDB cases fail.
• Reverting each fix makes its matching test fail, including the no-op update case for removeWrite.
• test:unit:resources at f66735f: 4706 passing on RocksDB. On LMDB, 3565 passing; 1 timing failure in subscriptionReplay.test.js (no source fill) passed 3 of 3 alone.
• At 9451dbc, not re-run since: test:unit:main 7765 passing; 24 integration CI shards green; caching.test.js, writeTargetReads.test.js, txn-tracking.test.js and the A write after ensureLoaded() on a RocksDB caching table is overwritten by the background source fill #2935 reproduction match main.

Test cases

• The resolved record replaces the invalidation in the log, and the record's local time points to it.
• A local write that commits while the fill waits on a gated blob save survives. The GET still returns source data first.
• A failed blob save releases the record, and a later read fills it.
• An invalidated record is removed on a source miss (delete logged). A concurrent local write survives a miss.
• The source writes the key it resolves through its context: put (invalidated and first fill), update (applied on top of the fill on RocksDB), invalidate, publish. A skipped stale source write and an update() that changes nothing do not block the fill.
• LMDB: the primary and log puts run inside the version-conditioned block. An append after the old log entry is pruned does not take another record's entry. A stale condition read is caught by the block.
• RocksDB: a write committed between the fill's read and its commit wins through the conflict retry.

PR QA: Do concurrent invalidate, GET and PUT on an LMDB caching table keep rows, indexes and the transaction log consistent across HTTP workers? — queued @ 9451dbc, qa-pr-harper-3529-9451dbc

Docs: none needed. No API, config or documented behavior changes.

_{🤖 Generated by Anthropic Claude Code (Claude Opus 5.5); posted via @kriszyp.}

🤖 Generated with Claude Code

https://claude.ai/code/session_017gfruVFyCm4swyps5CX9MH

Release target: main — no backport evidence; the LMDB log loss predates the shallow history, so a v5.3 cherry-pick is a customer-need call
Related PRs: #2155 overlaps (also edits the fill's commit handler), #3527 overlaps (adds residency capture to the fill's commit handler), 8 others independent
Complexity: complicated

Deferred findings

• 4cb21fc717fe62a3 minor data-integrity — resources/DatabaseTransaction.ts — RocksDB fill discarded on conflict retry leaves its first attempt's put:source log entry durable — NOT FILED
• 26bb2fcba9a5f76d minor correctness — resources/Table.ts — LMDB fill yields to a source-context update() on an invalidated key; the stub is replaced by the next refill, unlike RocksDB — NOT FILED
• fd827bbc3c0cd196 nit data-integrity — resources/RecordEncoder.ts — LMDB fill audit lookup precedes the native batch; a retention prune in between lets the replace put re-create the pruned key — NOT FILED

Late Grok findings

3 surviving (highest minor) — Grok reviewed 57de6b3

• minor — resources/Table.ts:9679 — On RocksDB, followsAppliedWrite() counts an earlier same-key write that has not run yet as applied. A source update() is staged with deferSave: true (resources/Table.ts:4852). The fill has no deferSave and no chainsStagedState, so addWrite saves it at once (`resources/DatabaseTransacti
• nit — resources/DESIGN.md:361 — The note says fill store writes "carry no condition of their own". The LMDB unaudited removal passes existingVersion as lmdb-js's positional ifVersion (resources/Table.ts:10138). Rewrite the sentence or name the exception.
• nit — resources/Table.ts:9677 — The helper's comment names relocate as an applied prior write, but no new test covers a same-key relocate before the fill.

Not standing: 1 separate-issue. Grok ran 13m (13m from launch to report); the fold adjudication (cursor-grok@57de6b30bd40-4040a58d, claude) took 1m.

Origin — the dispatch brief this PR was written from

Prove whether the per-put ifVersion on sourced cache fills is redundant, then remove it

_{Dispatch: task proposal-kriszyp-td-2026-09-11-resolve-source-double-ifversion-ae8e86 · queued by unknown · ran by claude/opus/high · worker kzyp-xps-1}

Late Grok findings

3 surviving (highest minor) — Grok reviewed 987fd15

• minor — resources/Table.ts:10025 — On LMDB, update(id, {name:'local'}) called through the source context while it resolves an invalidated key gets stored as an INVALIDATED stub (the patch-over-stub rule, resources/Table.ts:5580-5584). followsAppliedWrite then makes the fill yield, so the row stays invalidated. The next read r
• nit — resources/Table.ts:10023 — The comment, and resources/DESIGN.md:368, say LMDB's existingEntry is always the committed record. That is false on the exclusive fallback: resources/LMDBTransaction.ts:317-321 calls getEntry inside the native write transaction after the earlier same-key writes have been applied, so it sees
• nit — resources/DESIGN.md:361 — The 17-line note leaves the file at 998 lines against a 1000-line budget. DESIGN.md:10 says to prune a file near its ceiling before adding to it. check:design-docs still passes, so the next addition by anyone will fail it

Not standing: none. Grok ran 16m (16m from launch to report); the fold adjudication (cursor-grok@987fd1591e98-b3c7c30f, claude) took 2m.

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex; adjudicated=domain; declined=cursor-grok,muse; rounds=7; full=5 @ f66735f}

_{Review-Attention: study ~15m (critical: LMDBTransaction.ts, RecordEncoder.ts +1; decisions: lmdb-yields-to-source-write, batch-admission-only, fresh-local-time-when-audit-missing, detach-applies-to-all-lmdb-noops, design-note-drops-engine-caveats) @ f66735f}

[gemini-code-assist]

Code Review

This pull request refactors and documents how conditional writes and local timestamps are handled during source fills on LMDB and RocksDB, ensuring that source fills yield to earlier same-key writes and that audit entries are correctly managed. It also adds a comprehensive test suite to verify these race conditions. Feedback on the changes identifies an issue in the followsAppliedWrite helper function, where checking !prior.skipped is insufficient for deferred updates that were never saved, and suggests checking prior.saved && !prior.skipped instead to ensure only actually applied writes are yielded to.