Single-file readers refuse duplicate keys in all four runtimes; c0 bad-canonical row #110
2026-11-11
Merge remote-tracking branch 'origin/hands/reader-dup-keys-fix-rs' into reader-dup-keys
All checks were successful
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Successful in 25m31s
cultcache-rs: one commit guard for single-file writes refuses a second type under a held key
write_all_unlocked now refuses any snapshot holding a key twice (SchemaConflictError for two types), so insert_entry_if_absent, the compare-and-swap family, compare_exchange and the snapshot exchanges cannot bypass it; push and push_all lose their private copies. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-ts: pushAll keeps the last of same-type entries sharing a key
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Merge remote-tracking branch 'origin/hands/reader-dup-keys-fix-rs' into reader-dup-keys
Some checks failed
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Has been cancelled
cultcache-ts: refuse a duplicate key in a legacy envelope array; refuse a second type under a stored key on push and pushAll
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: refuse a second type under a held key; legacy arrays refuse duplicate keys
A single-file store holds one record per key. push and push_all now refuse (SchemaConflictError) a write that would put another type under a key, leaving file and cache unchanged, within one batch too; the legacy envelope-array decoder refuses a duplicate key like v1. Retyping is remove-then-add. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-py: refuse a legacy duplicate key; refuse a write that would retype a key
The legacy envelope-array decoder refuses a duplicate key as v1 does. The single-file writer refuses (SchemaConflictError, C# Retyped wording) a put/push_all that would land a second type under a key the store holds or the batch already names; file unchanged. Replace-by-key stays for the same type. Retyping is remove-then-add. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Add legacy-dup-key readability vector: legacy envelope array with key a under two types
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Merge remote-tracking branch 'origin/hands/reader-dup-keys-python' into reader-dup-keys
Some checks failed
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Has been cancelled
csharp: the one store reader refuses two records under one key
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: a store holding two records under one key is unreadable; the writer keeps one record per key
decode_store_snapshot refuses a repeated key (Undecodable). SingleFile push and push_all replaced by (type,key), so a write of another type to an existing key left two records under one key, which the reader now refuses; they now replace by key alone. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-ts: a present non-string canonical schema slot is refused; c0 bad-canonical joins the readability manifest
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-ts: decodeSnapshot refuses two records under one key; push replaces by key
The reader owns the verdict; the writer replaces an arrived record by key alone so it cannot emit a store the reader refuses. Store-file tests no longer pin one key under two types. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-py: refuse duplicate record keys and non-string canonical schema; writer replaces by key
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
vectors: duplicate-key stores are unreadable; keys are ordinal
Three dup-key vectors (same schema, other schema, different payload) refuse in all four runtimes; case and NFC/NFD distinct-key vectors read. Runtimes not yet cut: the dup rows are red until the runtime cuts land. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>