Check for parent of first ready block being on chain #1812
Conversation
When retrieveing the ready blocks, verify that the parent of the first ready block is on chain. If the parent is not on chain, we are downloading from a fork. In this case, keep downloading until we have a parent on chain (common ancestor)
dmitry-markin
added
R0-silent
|
@rahulksnv looks really nice! |
|
@rahulksnv Some tests are failing, could you look into that please? The important ones are in continuous-integration/gitlab-test-linux-stable, others are likely just a consequence of these failures. |
Looks like the first ready block is 1, and the parent (genesis block) is in |
I think it's correct to include |
|
Please merge if all looks good |
All is done. Thanks for fixing this! |
When retrieving the ready blocks, verify that the parent of the first ready block is on chain. If the parent is not on chain, we are downloading from a fork. In this case, keep downloading until we have a parent on chain (common ancestor). Resolves paritytech#493. --------- Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com> (cherry picked from commit 2b4b33d)
This reverts commit 2b4b33d.
…#1950) This reverts #1812 until we know why it causes syncing issues reported in autonomys/subspace#2122.
…aritytech#1812)"" This reverts commit 892bf8e.
The change adds a test to show the failure scenario that caused #1812 to be rolled back (more context: #493 (comment)) Summary of the scenario: 1. Node has finished downloading up to block 1000 from the peers, from the canonical chain. 2. Peers are undergoing re-org around this time. One of the peers has switched to a non-canonical chain, announces block 1001 from that chain 3. Node downloads 1001 from the peer, and tries to import which would fail (as we don't have the parent block 1000 from the other chain) --------- Co-authored-by: Dmitry Markin <dmitry@markin.tech>
When retrieving the ready blocks, verify that the parent of the first ready block is on chain. If the parent is not on chain, we are downloading from a fork. In this case, keep downloading until we have a parent on chain (common ancestor). Resolves paritytech#493. --------- Co-authored-by: Aaro Altonen <48052676+altonen@users.noreply.github.com>
…ech#1812)" (paritytech#1950) This reverts paritytech#1812 until we know why it causes syncing issues reported in autonomys/subspace#2122.
The change adds a test to show the failure scenario that caused paritytech#1812 to be rolled back (more context: paritytech#493 (comment)) Summary of the scenario: 1. Node has finished downloading up to block 1000 from the peers, from the canonical chain. 2. Peers are undergoing re-org around this time. One of the peers has switched to a non-canonical chain, announces block 1001 from that chain 3. Node downloads 1001 from the peer, and tries to import which would fail (as we don't have the parent block 1000 from the other chain) --------- Co-authored-by: Dmitry Markin <dmitry@markin.tech>
* Create CLI tool for generating indirect runtimes code * Use the generated runtime for rialto parachain * Avoid autogenerated files when executing cargo spellcheck * Fix clippy warning
When retrieving the ready blocks, verify that the parent of the first ready block is on chain. If the parent is not on chain, we are downloading from a fork. In this case, keep downloading until we have a parent on chain (common ancestor
Resolves #493.