-
Notifications
You must be signed in to change notification settings - Fork 709
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
[bridges] Prune messages from confirmation tx body, not from the on_idle #4944
Merged
acatangiu
merged 5 commits into
bko-bridges-v2-backport-refactoring
from
bko-bridges-v2-backport-pruning
Jul 10, 2024
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
4fbda94
prune messages from confirmation tx, not from the on_idle (#2211)
bkontur 28bdcf0
Added `do_try_state_for_outbound_lanes` which checks unpruned messages
bkontur 667641e
".git/.scripts/commands/bench/bench.sh" --subcommand=pallet --runtime…
7aa55e2
".git/.scripts/commands/bench/bench.sh" --subcommand=pallet --runtime…
fb8d0ba
Aviod iteration all the time to the beginning
bkontur File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
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'm not familiar with
try_state()
. Why do we useMAX_MESSAGES_ITERATION
and not iterate all the way ?Otherwise replacing the
loop
wit hafor
looks good.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.
Because, on every runtime upgrade it would be more and more waste of time, e.g.
Yes, that's why I updated description that maybe
oldest_unpruned_nonce
anddo_try_state_for_outbound_lanes
are not really needed.Slava wanted to create migration, that remove all messages <
oldest_unpruned_nonce
, but I think his concert was valid only if we have already more than one lane, becauseon_idle
he picked different/random lanes to prune depending onActiveOutboundLanes::count
, which is for fellows 1 :).I think MBM migration is too much for this andalso for standard migration, we would need to handle consumed weights and store last pruned block somewhere else, becauseoldest_unpruned_nonce
is incremented on delivery now.But as I am thinking about it again now, I think we should really remove attribute
lane.oldest_unpruned_nonce
, because we prune on delivery and this attribute does not make sense. So, the removal of this attribute could cause storage version change and migration, which would clean everything :)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.
actually, MBM migration and removed
oldest_unpruned_nonce
, would do the job :)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.
we don't use
oldest_unpruned_nonce
for relayer, anyway we can leave also without these migration, the worst can happen that we will have just a few messages in the storage, which we don't need. We add monitoring or do some sanity checks with seaching storage manually after upgrade, and when few messages left, we could remove them withset_prefix
/kill_storage
.