Migrated from ISSUES.md, which was retired in favour of GitHub issues. Original id I160, priority P3, from the 2026-07-02 deep review (docs/reviews/review-20260702-001902.md).
The text below is the triaged entry verbatim, including the corrections triage made to the original finding.
Where: src/membership_index.rs:243
Problem: Latent, unreachable-from-public-API inconsistency in the pub(crate) RadixU64: insert(key = u64::MAX) infinite-loops in the grow() while-loop (capacity saturates at u64::MAX for depth >= 6, and grow has no MAX_DEPTH cap), and delete lacks find_leaf's cap != u64::MAX exemption (benign today since u64::MAX can never be inserted, but contradicts find_leaf's documented u64::MAX support). Production keys are u32 tags and validated engine-minted handles, so no external input reaches these paths; fix is a one-line MAX_DEPTH cap / error in the grow loop plus mirroring find_leaf's guard in delete. Same runaway grow-and-allocate loop; same internal contradiction with find_leaf's explicit u64::MAX support and the MAX_DEPTH comment (lines 22-27, "forces one final grow to depth 6"). Unreachable in practice via engine-assigned handles / u32 tags, but latent for any future in-crate caller of the generic radix.
Direction of fix: Add && self.depth < MAX_DEPTH to the grow loop (or a MAX_DEPTH no-op in grow, matching FreeMapTree::grow), and align delete's capacity guard with find_leaf's saturated-capacity exemption.
Migrated from
ISSUES.md, which was retired in favour of GitHub issues. Original id I160, priority P3, from the 2026-07-02 deep review (docs/reviews/review-20260702-001902.md).The text below is the triaged entry verbatim, including the corrections triage made to the original finding.
Where:
src/membership_index.rs:243Problem: Latent, unreachable-from-public-API inconsistency in the pub(crate) RadixU64: insert(key = u64::MAX) infinite-loops in the grow() while-loop (capacity saturates at u64::MAX for depth >= 6, and grow has no MAX_DEPTH cap), and delete lacks find_leaf's cap != u64::MAX exemption (benign today since u64::MAX can never be inserted, but contradicts find_leaf's documented u64::MAX support). Production keys are u32 tags and validated engine-minted handles, so no external input reaches these paths; fix is a one-line MAX_DEPTH cap / error in the grow loop plus mirroring find_leaf's guard in delete. Same runaway grow-and-allocate loop; same internal contradiction with find_leaf's explicit u64::MAX support and the MAX_DEPTH comment (lines 22-27, "forces one final grow to depth 6"). Unreachable in practice via engine-assigned handles / u32 tags, but latent for any future in-crate caller of the generic radix.
Direction of fix: Add
&& self.depth < MAX_DEPTHto the grow loop (or a MAX_DEPTH no-op ingrow, matching FreeMapTree::grow), and aligndelete's capacity guard withfind_leaf's saturated-capacity exemption.