Skip to content

Fix stale revert target in polling block stream#6421

Open
incrypto32 wants to merge 3 commits intomasterfrom
krishna/fix-stale-revert-target
Open

Fix stale revert target in polling block stream#6421
incrypto32 wants to merge 3 commits intomasterfrom
krishna/fix-stale-revert-target

Conversation

@incrypto32
Copy link
Member

Subgraphs far behind chain head (> reorg_threshold blocks) get stuck in an infinite revert loop when sitting on a stale block from an old reorg. is_on_main_chain correctly identifies the stale block, but parent_ptr fetches the stale block's parent from the block cache — a hash from the pre-reorg chain that no longer exists on the canonical chain.

  • Change is_on_main_chain to return Option<BlockPtr> instead of boolNone means on main chain, Some(canonical_parent) is the revert target
  • Polling block stream uses the canonical parent directly instead of looking up the stale block's cached parent
  • Improve revert error message in the store to mention stale blocks as a possible cause

Change `TriggersAdapter::is_on_main_chain` to return `Option<BlockPtr>`
instead of `bool`. `None` means the block is on the main chain;
`Some(canonical_parent)` provides the revert target directly from the
canonical chain.

Previously, when a subgraph far behind chain head sat on a stale block
from an old reorg, the revert target was derived from the stale block's
cached parent_hash — a hash from the pre-reorg chain that may no longer
exist. This caused permanent revert failures and an infinite retry loop.

Now the Firehose path returns the canonical block's parent_ptr() and the
RPC path uses next_existing_ptr_to_number(N-1), both sourced from the
canonical chain.
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.

1 participant