From 328e9b37e1b310f2b3ae0d283c35795254e2f6eb Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Thu, 15 Oct 2026 00:23:25 +0200 Subject: [PATCH] HeaderForWrite comment: only a reader with the record's type can tell from its bytes whether it holds an element id Co-Authored-By: Claude Sonnet 5.5 --- src/GameCult.Caching/CultCache.cs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/GameCult.Caching/CultCache.cs b/src/GameCult.Caching/CultCache.cs index 9d491704..c90fdfcc 100644 --- a/src/GameCult.Caching/CultCache.cs +++ b/src/GameCult.Caching/CultCache.cs @@ -3545,8 +3545,9 @@ namespace GameCult.Caching return directoryStore ? DirectoryFormatV4 : holdsVariants ? CultPersistedStoreSnapshot.FormatV2 : CultPersistedStoreSnapshot.FormatV1; } - // The header a write leaves, for either store kind: HeaderFor decides. A record's bytes do not say whether it holds an - // element id (an id is an ordinary keyed string), so only the store header carries that fact. A write that copies any + // The header a write leaves, for either store kind: HeaderFor decides. An element id is an ordinary keyed string, so only a + // reader with the record's type can tell from its bytes whether it holds one; the store header is how a reader without the types + // learns it. A write that copies any // record forward keeps a marked header; a write that encodes every record the store will hold decides by content. An // opaque payload (null) never marks an unmarked store, and keeps a marked one marked. A copied record the writer decodes // under the store's lock holding an id marks the store too (SingleFileBackingStore.CopiedHoldIds): another runtime may