graf/GET.c builds per-side membership maps base_ids / tgt_ids with only 4096 slots, while the version cap GET_MAX_VERS is 200000. A file with more than 4096 versions overruns the map: u8bFeed1 returns SNOROOM and the id is SILENTLY DROPPED (no error surfaced), so membership is computed against an incomplete set โ a correctness loss, not a crash. Spotted auditing the weave path while fixing PATCH-004; out of that ticket's scope. Method Issues.
graf/GET.c sizes base_ids/tgt_ids at 4096 entries; GET_MAX_VERS = 200000. Thetwo limits disagree by ~50x, so any file with >4096 versions exceeds the map.
u8bFeed1(...) returning SNOROOM whose result is not gated, sothe membership id is dropped without a trace (silent wrong answer in get/diff sizing).
is unrelated to the cherry-pick use-after-scope.
GET_MAX_VERS, or grow ondemand) so no id is dropped for a large-history file.
u8bFeed1/sFeed return), never asilent SNOROOM drop.
(CLAUDE.md ยง17): a file with >4096 versions exercised through the graf GET path, asserting every membership id is present (RED today). Don't regress small-history get.
u8bFeed1 call site in graf/GET.c; decide
fixed-to-GET_MAX_VERS vs a growable buffer; gate the feed return either way.
base_ids/tgt_ids and check the feed return (loud on overrun).
Audit 2026-07-07 pinpoints (still live): u32bMap(base_ids, 4096)/u32bMap(tgt_ids, 4096) at graf/GET.c:327-328; the unchecked drop is (void)u32bFeed1(base_ids, WEAVE_WT_SRC) at :359 plus the collect-side feeds behind :350/:364; GET_MAX_VERS=200000 at :35 (the u32b* family, not u8bFeed1 as first filed; GET_TREE_MAX_ENTRIES 4096 at :38 is a separate limit).
histories, so not urgent but should not stay latent.