Spun out from #20805 review.
Problem
Test_ModeUpdate_SiblingConsistency (execution/commitment/hex_patricia_hashed_test.go) is currently t.Skip(...). It documents a real correctness bug: when only a subset of sibling accounts is touched in a follow-up block, ModeUpdate produces a different trie root than ModeDirect — the untouched sibling cell is being hashed instead of inlined, so the branch node's encoding diverges.
Why this matters
ModeUpdate is the path used by the parallel commitment calculator. ModeDirect is the serial baseline. Any divergence means the parallel calculator can produce a wrong trie root under specific multi-block patterns.
Why it's not blocking PR #20805 today
The failing scenario is constructed (two sibling accounts with shared branch prefix, modified in B1, only one touched in B2). Production traffic on this PR has not hit it across 13,696/13,696 PASS in the eest_devnet sweep. We need to confirm via mainnet-replay whether real chain inputs ever produce this geometry — if yes, this becomes a merge blocker on the parallel-calc work.
Fix sketch
Cell-cache invalidation in HexPatriciaHashed. The cached cell from B1 is being reused in B2 instead of re-encoded against the touched sibling's new state. Either invalidate the cached cell on any update to a sibling under the shared prefix, or re-derive from current accounts when emitting the branch.
Test
Re-enable Test_ModeUpdate_SiblingConsistency (remove t.Skip) — it is the regression marker.
Spun out from #20805 review.
Problem
Test_ModeUpdate_SiblingConsistency(execution/commitment/hex_patricia_hashed_test.go) is currentlyt.Skip(...). It documents a real correctness bug: when only a subset of sibling accounts is touched in a follow-up block, ModeUpdate produces a different trie root than ModeDirect — the untouched sibling cell is being hashed instead of inlined, so the branch node's encoding diverges.Why this matters
ModeUpdate is the path used by the parallel commitment calculator. ModeDirect is the serial baseline. Any divergence means the parallel calculator can produce a wrong trie root under specific multi-block patterns.
Why it's not blocking PR #20805 today
The failing scenario is constructed (two sibling accounts with shared branch prefix, modified in B1, only one touched in B2). Production traffic on this PR has not hit it across 13,696/13,696 PASS in the eest_devnet sweep. We need to confirm via mainnet-replay whether real chain inputs ever produce this geometry — if yes, this becomes a merge blocker on the parallel-calc work.
Fix sketch
Cell-cache invalidation in HexPatriciaHashed. The cached cell from B1 is being reused in B2 instead of re-encoded against the touched sibling's new state. Either invalidate the cached cell on any update to a sibling under the shared prefix, or re-derive from current accounts when emitting the branch.
Test
Re-enable
Test_ModeUpdate_SiblingConsistency(removet.Skip) — it is the regression marker.