cultcache-ts: opening a legacy store never rewrites it #85

Merged
libby merged 1 commit from libby/legacy-store-no-heal-on-open into main 2026-11-10 23:56:57 +00:00
Member

The TS single-file MessagePack store rewrote a pre-v1 legacy envelope-array file as v1 while opening it, before the consumer's codec had accepted the content. A codec that then refused left the old bytes gone (StreamPixels, web-customize settings-legacy-heal-rewrites-before-refuse).

Change (TS only; Python and Rust never healed on read, C# has no legacy format):

  • pullAll is a pure read: legacy payloads are normalized in memory, the file is untouched. The file becomes v1 only on the consumer's next push/delete/pushAll, which already merge what they read.
  • repairedLegacyPayload removed from SingleFileStoreRead (no consumer in packages/*, src).
  • Tests: opening writes nothing and leaves no lock/temp; a refusing codec leaves the bytes identical; a later push writes v1 and keeps the other legacy entries. Vectors are SYNTHETIC (no real pre-v1 file exists): a top-level MessagePack array of {key,type,payload,storedAt} with payload an object, Node Buffer JSON, or an int array. Pins in Python and Rust that pull leaves the legacy bytes identical.

Verified: store-file and cult-cache TS tests, Python 76/76, Rust pin. Soul pass held; hand mutations (rewrite on pull in two forms, normalization dropped, push dropping other entries) all fail tests. The 12 TS failures in this sandbox (interop, esbuild entry) fail identically on main. Rust pull_all creates a .lock file beside a legacy file, same as main; bytes unchanged.

🤖 Generated with Claude Code

The TS single-file MessagePack store rewrote a pre-v1 legacy envelope-array file as v1 while opening it, before the consumer's codec had accepted the content. A codec that then refused left the old bytes gone (StreamPixels, web-customize settings-legacy-heal-rewrites-before-refuse). Change (TS only; Python and Rust never healed on read, C# has no legacy format): - `pullAll` is a pure read: legacy payloads are normalized in memory, the file is untouched. The file becomes v1 only on the consumer's next push/delete/pushAll, which already merge what they read. - `repairedLegacyPayload` removed from `SingleFileStoreRead` (no consumer in packages/*, src). - Tests: opening writes nothing and leaves no lock/temp; a refusing codec leaves the bytes identical; a later push writes v1 and keeps the other legacy entries. Vectors are SYNTHETIC (no real pre-v1 file exists): a top-level MessagePack array of {key,type,payload,storedAt} with payload an object, Node Buffer JSON, or an int array. Pins in Python and Rust that pull leaves the legacy bytes identical. Verified: store-file and cult-cache TS tests, Python 76/76, Rust pin. Soul pass held; hand mutations (rewrite on pull in two forms, normalization dropped, push dropping other entries) all fail tests. The 12 TS failures in this sandbox (interop, esbuild entry) fail identically on main. Rust `pull_all` creates a `.lock` file beside a legacy file, same as main; bytes unchanged. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
cultcache-ts: opening a legacy store is a pure read; no heal-on-open
Some checks failed
CultMesh QUIC native / Build win32-x64 (pull_request) Has been skipped
CultMesh QUIC native / Build linux-x64 (pull_request) Has been skipped
CultMesh QUIC native / Release native binaries (pull_request) Has been skipped
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Has been cancelled
CultMesh QUIC native / Verify committed binaries match SHA256SUMS (pull_request) Has been cancelled
aa8d8ddd6b
Delete the pullAll rewrite and SingleFileStoreRead.repairedLegacyPayload (no consumer). The file becomes v1 on the next push/delete/flush. Tests use a synthetic pre-v1 vector; Python and Rust pins added.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
libby merged commit 44149afb7b into main 2026-11-10 23:56:57 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
GameCult/CultLib!85
No description provided.