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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: during resharding, reassign outgoing receipts to lowest index child #9362
fix: during resharding, reassign outgoing receipts to lowest index child #9362
Changes from 1 commit
3b7ff0b
c7db158
6dc1e69
df4a193
0f38dca
985397f
9b0d13c
275ebce
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@robin-near, just for my understanding, when is it possible for the prev_block_height to not be last_included_height? Is it when we have an orphan block chain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it's when a block is missing a chunk. Then the last_included_height will be the latest block height where a chunk for the shard is present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, what @wacban said. It's one of the very cryptic parts of the codebase - chunks can be missing from blocks, and the logic to handle that is very complex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this handle when split shards are in the middle of shard IDs, e.g. 1 -> 1,2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In resharding as you described we would have:
0->0' ; 1->1', 2' ; 2->3' ; 3->4'
shard 0', 1', 3', 4' each will get all of the ougoing receipts from their respective parent shard
shard 2' will get no outgoing receipts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I was wondering how this remapping happen for non split shards (e.g. shard 2 and 3 in the example above) since the function seem to care only about split shard ids.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For non-split shards we treat it as splitting a parent shard into a single child shard. So it is covered here. In the example above shard 3' will get all of the outgoing receipts from its parent shard 2 and shard 4' will get all of the outgoing receipts from its parent 3.
Currently because of how storage keys work we need to copy all of the data from shards that are not split anyway. In the future we'll likely optimize that. Assuming we decide to have unique, incremental shard ids (e.g. 0, 1, 2, 3 -> (splitting 1) -> 0, 2, 3, 4, 5) then the outgoing receipts reassignment will be to keep the receipts where they are for non-split shards and reassign to lowest index child for split shards.