From b292f2a8ab89d5c749143250b39958b87d85d764 Mon Sep 17 00:00:00 2001 From: Kris Zyp Date: Tue, 27 Oct 2026 08:22:16 -0600 Subject: [PATCH] Bring resources/DESIGN.md back under its 1000-line budget #3529's source-fill note was hard-wrapped at 100 columns, while the file writes one line per paragraph; that pushed the file to 1001 lines and turned the Lint workflow's check:design-docs step red on main. Rejoin the note onto one line. No words change. Co-Authored-By: Claude Opus 5.5 Dispatch-Task: main-red-kriszyp_harper_1691ea012_5684deb1 --- resources/DESIGN.md | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/resources/DESIGN.md b/resources/DESIGN.md index 6650a1b198..c5f163c9c9 100644 --- a/resources/DESIGN.md +++ b/resources/DESIGN.md @@ -341,17 +341,7 @@ bit is persisted, so it cannot follow a renumbered rocksdb-js constant without a `unitTests/resources/caching-rocks-database.test.js` ('marks a record whose version was reused…') pins the layout against raw stored values. -A fill's puts carry no condition of their own: on LMDB the `LMDBTransaction` `ifVersion` block holds -the condition with the primary, index and audit puts in one native write transaction (a per-put -`ifVersion` cannot stop the index writes, and on the unversioned audit store it drops the write); on -RocksDB a conflict retries the commit handler. A write the source makes to the same key through its -context joins the fill's transaction, where neither check sees it. RocksDB reads the fill's -`existingEntry` through that transaction; LMDB's optimistic path reads the committed record, so on -LMDB the fill yields to any earlier same-key write not skipped (`followsAppliedWrite`), and a no-op -`update()` removed at validation leaves the per-key chain (`LMDBTransaction.removeWrite`). On LMDB an -invalidated record keeps its local time only while its audit entry exists to be replaced -(`recordUpdater`), since an appended entry is keyed by the last assigned time. -`unitTests/resources/sourceFillConditionalWrite.test.js` pins both engines. +A fill's puts carry no condition of their own: on LMDB the `LMDBTransaction` `ifVersion` block holds the condition with the primary, index and audit puts in one native write transaction (a per-put `ifVersion` cannot stop the index writes, and on the unversioned audit store it drops the write); on RocksDB a conflict retries the commit handler. A write the source makes to the same key through its context joins the fill's transaction, where neither check sees it. RocksDB reads the fill's `existingEntry` through that transaction; LMDB's optimistic path reads the committed record, so on LMDB the fill yields to any earlier same-key write not skipped (`followsAppliedWrite`), and a no-op `update()` removed at validation leaves the per-key chain (`LMDBTransaction.removeWrite`). On LMDB an invalidated record keeps its local time only while its audit entry exists to be replaced (`recordUpdater`), since an appended entry is keyed by the last assigned time. `unitTests/resources/sourceFillConditionalWrite.test.js` pins both engines. ## Blob orphan cleanup: pre-saved files outlive cancelled commits