Repository navigation
fix(testnet): recover safely from source reorgs - #151
Merged
Merged
Conversation
sprites0
force-pushed
the
fix/pseudo-peer-recover-evicted-blocks
branch
4 times, most recently
from
September 1, 2026 05:35
90b1f85 to
18be869
Compare
sprites0
changed the title
sprites0
force-pushed
the
fix/pseudo-peer-recover-evicted-blocks
branch
4 times, most recently
from
September 3, 2026 15:21
b43b8ef to
4e02d2b
Compare
sprites0
marked this pull request as ready for review
September 3, 2026 15:27
sprites0
force-pushed
the
fix/pseudo-peer-recover-evicted-blocks
branch
4 times, most recently
from
September 4, 2026 07:55
5b1676c to
6a8b71c
Compare
sprites0
force-pushed
the
fix/pseudo-peer-recover-evicted-blocks
branch
3 times, most recently
from
November 10, 2026 08:13
ec9a551 to
0916499
Compare
Keep enough canonical history available for deep reorgs, avoid prematurely finalizing imported heads, and serve blocks with receipts from one consistent database snapshot.
Reth can begin a falling header request at a child's parent, but the reorg cache refactor stopped recording that parent mapping and caused repeated empty responses. Index each fetched block's parent at the preceding height and cover the lookup with a focused regression test.
get_by_hash only served from the `blocks` LRU, which holds BLOCK_CACHE_LIMIT (100k) entries. The hash index holds ten times that (HASH_INDEX_LIMIT, 1M) and falls back to the node's HeaderNumbers table on a miss, so a hash stays resolvable long after its body has been evicted. Every peer request for such a hash failed with "Block not cached for hash", even though the block was still reachable by number. Resolve the hash to a height and refetch instead: serve from gap_blocks when the height is one of the hardcoded testnet gaps, otherwise call the source under a 30s timeout so a stalled fetch cannot wedge the request loop. Recovery is only allowed to install a block that is provably the one asked for. The source is a by-number API, so it can legitimately return a different block than requested after a reorg; three checks reject that. The returned block must be at the requested height and carry the requested hash, and — under the canonical_hashes write lock — must not contradict a hash already recorded for that height. The last check is what closes the race: an in-flight recovery that finishes after cache_block has refreshed the height loses, rather than overwriting the newer canonical block with the one it happened to fetch. The staleness check in BlockImport::poll was using get_by_hash's error as its signal, which is wrong in both directions now. It would trigger a source fetch on what is only a liveness test, and a hash that reorged away but still resolves through the DB index would come back Ok and be treated as live. Add is_cached_canonical_hash, which answers exactly that question with no I/O: the body is cached and its hash is still canonical at its height. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Z9cmqnwb9tL9kxkGM5Ccb
canonical_hashes gained an entry for every cached block and was only trimmed by invalidate_above, which mainnet effectively never reaches, so a node syncing from genesis kept one entry per height. Evicting a block from the LRU now drops its canonical entry as well. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
sprites0
force-pushed
the
fix/pseudo-peer-recover-evicted-blocks
branch
from
November 10, 2026 09:58
0916499 to
2bfab61
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Enable Hyperliquid testnet nodes to recover from source reorgs within a 256-block window while preserving immediate finality on mainnet.
Changes
998)999)Safety
Reorg support is selected from the chain ID. Mainnet and unknown chains use immediate finality; only testnet receives the 256-block reorg window.
Testing