Skip to content

fix(store): detect single-block overflow in reconstruct_storage_map_from_db#1824

Closed
mmagician wants to merge 4 commits into0xMiden:release/v0.14.0-alphafrom
mmagician:mmagician-claude/fix-reconstruct-overflow
Closed

fix(store): detect single-block overflow in reconstruct_storage_map_from_db#1824
mmagician wants to merge 4 commits into0xMiden:release/v0.14.0-alphafrom
mmagician:mmagician-claude/fix-reconstruct-overflow

Conversation

@mmagician
Copy link
Contributor

Summary

  • Follow-up to #1816 which fixed the panic in select_account_storage_map_values_paged
  • That fix correctly signals "no progress" when a single block exceeds the pagination limit, but reconstruct_storage_map_from_db (the caller) doesn't detect it
  • The loop exits at the top when last_block_included == block_num (both 0 for genesis), before reaching the progress check inside the loop body
  • Result: returns AllEntries([]) instead of LimitExceeded, causing the client to import genesis accounts with empty storage maps
  • Fix: add an early check after the first page - if no values were returned and no progress was made, return LimitExceeded

Test plan

  • Added test reconstruct_storage_map_from_db_returns_limit_exceeded_for_genesis_overflow that fails without the fix (AllEntries([])) and passes with it (LimitExceeded)
  • Full miden-node-store test suite passes (124 tests)
  • Verified end-to-end: client integration test import_account_with_large_storage_map imports the genesis test account with 2000 storage map entries

🤖 Generated with Claude Code

…rom_db

The previous pagination fix in `select_account_storage_map_values_paged`
correctly signals "no progress" by returning empty values when a single
block exceeds the entry limit. But the caller
(`reconstruct_storage_map_from_db`) didn't detect this because the
loop exits at the top when `last_block_included == block_num` (both 0
for genesis), before reaching the progress check inside the loop body.

This resulted in returning `AllEntries([])` instead of `LimitExceeded`,
causing the client to import genesis accounts with empty storage maps.

Add an early check after the first page: if no values were returned
and we didn't advance past the starting block, the block has more
entries than the limit allows, so return `LimitExceeded`.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@mmagician mmagician force-pushed the mmagician-claude/fix-reconstruct-overflow branch from bbdcd9e to a9bb1e4 Compare March 23, 2026 19:58
claude added 3 commits March 23, 2026 20:32
…tion

Replace `last_block_num.saturating_sub(1)` with reading block_num from
the last kept `AccountVaultValue`. Same approach as the storage map fix
in 0xMiden#1816.

No unit test added because `select_account_vault_assets` uses a
hardcoded `MAX_ROWS` (~61k) derived from `MAX_RESPONSE_PAYLOAD_BYTES`,
making it impractical to trigger the overflow in a test.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…pagination

Replace `last_block_num.saturating_sub(1)` with reading block_num from
the last kept `TransactionRecordRaw`. Same approach as the storage map
fix in 0xMiden#1816.

This is unlikely to be triggered in practice (genesis blocks don't have
transactions, and a single non-genesis block is unlikely to exceed the
4MB size-based limit), but we fix it for consistency and safety.

No unit test added because the function uses `MAX_RESPONSE_PAYLOAD_BYTES`
(4MB) as the size limit, making it impractical to trigger in a test.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…agination

Replace `last_created_at_block.saturating_sub(1)` with a backward scan
to find the last kept row's block number. Uses reverse iteration to
avoid an extra allocation (AccountId has no block_num field, so we
can't use the single-pass approach from the other fixes).

No unit test added because the function uses a hardcoded MAX_ROWS
(~61k) that is impractical to trigger in a test.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@mmagician mmagician marked this pull request as ready for review March 23, 2026 20:53
@mmagician
Copy link
Contributor Author

superseded by #1825

@mmagician mmagician closed this Mar 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants