cumulus: Remove max_depth for the parent search#10973
Merged
Conversation
We were just incrementing this number all the time and there is actually no need to have it, as the search is already automatically bounded. For chains with 500ms blocks and relay offset of 1 we easily go above this limit and this then leads to forks. So, let's remove the value.
sandreim
approved these changes
Feb 3, 2026
skunert
approved these changes
Feb 3, 2026
lexnv
reviewed
Feb 3, 2026
| // we can guarantee that all imported blocks respect the unincluded segment | ||
| // rules specified by the parachain's runtime and thus will never be too deep. This is just an extra | ||
| // sanity check. | ||
| const PARENT_SEARCH_DEPTH: usize = 40; |
Contributor
There was a problem hiding this comment.
Would it be worth bumping this to 256 instead? It might be a good safeguard, not sure what other defaults we have in code tho
Member
Author
There was a problem hiding this comment.
You can only go back to the included block and the list of pending blocks can not grow infinite.
lexnv
approved these changes
Feb 3, 2026
Contributor
lexnv
left a comment
lexnv
left a comment
There was a problem hiding this comment.
For 20mins of data for 12cores parachains:
- 945 imported total blocks
- 911
[Parachain] 🏆 Imported #560302
The chance of forked blocks is ~4%, which stabilizes the block times around 0.85s ~ 0.95s.
Member
Author
|
/cmd prdoc --audience node_dev --bump major |
…e_dev --bump major'
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Feb 18, 2026
While reviewing #10973 I found once more that our parent search is totally overengineered: - It offers the option to search branches that do not contain the pending block -> These branches can never be taken - It returns a list of potential parents -> Nobody uses the list, we only care about the latest block that we should build on By eliminating these two annoyances, the code is a lot more simple and easier to follow. There are still some defensive checks that are not strictly necessary, but does not hurt to keep them. In summary, the mental model is: Build on the latest descendant of the pending block that is still inside the relay parent ancestry. If no pending block is available, use the included block in its place. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
github-project-automation
Bot
moved this from Todo
to Done
in [preview] release tracker
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
5 participants
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.
We were just incrementing this number all the time and there is actually no need to have it, as the search is already automatically bounded. For chains with 500ms blocks and relay offset of 1 we easily go above this limit and this then leads to forks.
So, let's remove the value.