Add MaxRollbackDepth to prevent deep reorg processing - #3
Conversation
Add optional MaxRollbackDepth parameter to WalkerOptions to stop the walker service when a reorg exceeds the configured depth limit. - Added MaxRollbackDepth int64 field to WalkerOptions (0 = unlimited) - Updated undoBlocks() to check rollback depth during backtracking - Walker stops (returns running=false) if depth exceeds limit This prevents processing dangerous deep reorgs that could corrupt downstream state by stopping before emitting an undo command.
|
Sorry, not quite working as expected during e2e test. Moved to draft |
…g incomplete undo When MaxRollbackDepth is exceeded, undoBlocks() was returning a partially populated undo object (with UndoBlocks but without LastValidHeight/LastValidHash). This could allow an invalid undo command to be sent to consumers. Fix: - Return nil instead of incomplete undo when limit exceeded - Add nil checks in callers before sending undo commands This ensures deep reorgs exceeding the limit are properly stopped without sending invalid undo commands, while normal reorgs continue to work correctly.
- Add MaxRollbackWaitDuration option to WalkerOptions - Implement wait and retry mechanism when MaxRollbackDepth is exceeded - When deep reorg detected, wait configured duration before retrying - Prevents restart loop by giving RPC node time to re-index - Zero value (0) means return immediately (backward compatible) - Default wait duration: 5 seconds (configured in indexer)
|
In this implementation, if the max undo block length is surpassed, the walker would resume once it reaches a new tip, and it wouldn't emit an undo. This would work in the case of a re-indexing, but perhaps not for some other event such as corruption. |
|
@raffecat this PR has been sitting for a while, related PR indexer I may close this one soon if it's not useful, or if there is another plan you have in mind. The main reason for this PR was the concern that if someone inadvertently causes a dogecoin node rollback, or a new dogecoin node is introduced without it being in the correct state, we could be waiting some time for a deep reorg in current state. It sounds like there are other ways to potentially seed indexer in future state, so can understand if you may perfer not to add this feature. |
1 participant
Add optional MaxRollbackDepth and MaxRollbackWaitDuration parameters to WalkerOptions to gracefully handle deep reorgs that exceed the configured depth limit.
The wait-and-retry mechanism give the core node time to re-index after a deep reorg, allowing the walker to resume once blocks are back on-chain.
Example output while waiting:
And ones re-indexing catches up...