-
Notifications
You must be signed in to change notification settings - Fork 378
Ensure outgoing XCMP respects unincluded segment #2471
Comments
Ok, UMP is fully addressed as-of #2501 . HRMP will require some tweaks to the Investigating this also raised another issue, which is weight calculation. We need to calculate the weight of cumulus/pallets/parachain-system/src/lib.rs Lines 309 to 326 in 5892628
We may need to adapt some similar strategy of "predicting" the amount of bandwidth we can use in |
or use |
This would be: paritytech/polkadot-sdk#82 However, I don't think that we need this there. In general I would assume that the host configuration is changed in a way to allow "more". Reducing something is probably never gonna happen. Nevertheless, we can use the "old" host configuration to calculate the weight. We then just need to ensure to that |
Looks like the implementation of About the HostConfig/weight thing: |
How's it insured for the whole segment of unincluded blocks? |
It may be that only the number of channels we can send messages on impacts the weight, so that logic would remain correct. Still, we need to determine the maximum sizes at every block and then load that maximum repeatedly during the It would be cleaner for the |
Turned out the simplest way to do this was to update the |
Closed by #2948 |
I believe this trait not only should account for max messages taken from the storage, but also for segment limitations if we want to make this panic correct.
Probably primitives for segment should be extracted into common crate to be accessible from both pallets.
Originally posted by @slumber in #2438 (comment)
The text was updated successfully, but these errors were encountered: