Fix reorg handling #5819
Merged
Fix reorg handling #5819
Conversation
This file contains 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
and FullNode The custom implementations triggered to repeat requests but we shut down the seed node in case of a reorg and for desktops we request the user to shutdown.
…tion We trigger a resync from resources if there is a reorg and don't want to continue to request blocks
persistance is below the chain height of btc core. With the new handling of dao state hashblocks it can be the we have persisted the latest block up to the chain height. Before that change we only had the last snapshot which was at least 20 blocks back persisted. We want to avoid to get caught in a retry loop at parseBlocksOnHeadHeight so we filter out that case just at the caller. At parseBlocksOnHeadHeight we inline the requestChainHeadHeightAndParseBlocks method as it is not used by other callers anymore. This case that we request a block but our local btc core chain hight is below that might be some edge case when we had a synced dao blocks but we btc core is resyncing...
We shut down with a deterministic delay per seed to avoid that all seeds shut down at the same time in case of a reorg. We use 30 sec. as distance delay between the seeds to be on the safe side. We have 12 seeds so that's 6 minutes.
ripcurlx
approved these changes
Nov 12, 2021
There was a problem hiding this comment.
ACK - Tested the process on Regtest and was able to simulate the behavior as described.
- Seednode shut down
- Full node got notified to shut down
- Light node didn't recognize the reorg yet
- Seednode and Alice (fullnode) were restarted
- After creating new blocks, Bob (light node) recognized the reorg
After restart of Light node everything went back to normal.
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.
Fixes #5809
How to reproduce:
In master the Alice nad Bob nodes get caught in an endless loop requesting new blocks. The seed node is shut down automatically. Bob will start the endless loop only after the seed has restarted and the next block is propagated.
With the PR version there is just the shutdown at seed node and the shutdown popup at desktop apps but no loops.
The litenode will not recognize the new block as the full nodes are shut down or inactive. Only after restarting the seed and creating a new block the lite node will detect the reorg. The block propagation is delayed with a random delay so it can take a bit...
To avoid that all seed nodes shut down at the same time when a reorg happens we add a detereministic delay derived from the index of the seed in the seed node list. So shut down is delayed by 30 sec * index, distributing the shutdown of 12 seeds over 6 minutes.