XCM: Implement a blocking barrier #6670
Conversation
KiChjang
added
A0-please_review
| #[pallet::call_index(10)] | ||
| #[pallet::weight(100_000_000u64)] | ||
| pub fn force_suspension(origin: OriginFor<T>, suspended: bool) -> DispatchResult { | ||
| ensure_root(origin)?; |
There was a problem hiding this comment.
Should probably be a configuration item.
There was a problem hiding this comment.
I don't think this actually does what it's meant to do.
This type would include the
Suspendedvariant meaning "does not pass this barrier yet, but it might pass in a later block" .
This meaning was not implemented. It will need to be integrated properly into the Message Queue systems (i.e. pallet message queue), so they stop executing messages from any origin which returns Suspended until some time in the future (e.g. the next block).
As it stands it will do the same as it would for any other non-passing barriers: just drop the messages. Definitely not the intended behaviour.
|
I observe the PR includes a db read made by a barrier. I am assuming this could produce an unpaid db read, is it not that much of an issue because it can at most spam one db read per block? (I am assuming following messages processed in the same block will have the db read cached?) |
|
This should help paritytech/substrate#13424 |
|
@KiChjang you going to get this one over the line now? With the |
|
Wouldn't this be blocked on #6271 before we can actually use the queues here? |
|
possibly, but it doesn't matter - the API is in. |
|
Will reopen this PR with some changes. |
Rebased version of #5035.
Fixes #4813.
cumulus companion: paritytech/cumulus#2174