pallet-message-queue: add queue pausing#14318
pallet-message-queue: add queue pausing#14318paritytech-processbot[bot] merged 3 commits intomasterfrom
pallet-message-queue: add queue pausing#14318Conversation
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
gavofyork
left a comment
There was a problem hiding this comment.
Seem harmless enough, but what about migrations?
Its not changing any storage - just adding a |
| } | ||
|
|
||
| /// Provides information on paused queues. | ||
| pub trait QueuePausedQuery<Origin> { |
There was a problem hiding this comment.
As a design nit, I sometimes wonder if we should avoid creating a new trait like this when it can be easily expressed by Convert<Origin, bool> (cc @gpestana this is similar to my comment in #13983 (comment) 🙈).
No strong opinion myself, but I might personally lean into reusing Convert more and more.
There was a problem hiding this comment.
Interesting idea. Yes I also dont like having tons of trivial traits.
The only problem i see with Convert is on the implementor side. When seeing impl<T: Config> Convert… for Pallet<T>, it is not clear what it means. Maybe we can use type alias for that, or something similar.
There was a problem hiding this comment.
Maybe we could use the frame_support::Get trait instead? The type name is explicitly enough to use the getter trait and it things readable.
There was a problem hiding this comment.
Suppose we have impl Get<bool> for Pallet<T>.
Now from the implementor side what does this mean? Anyone seeing this code will have no idea what it means.
kianenigma
left a comment
There was a problem hiding this comment.
LGTM. I would suggest double checking that all code-paths leading into servicing queues is blocked, as I could not be sure that the places that are already checked are not missing anything.
Otherwise it would not start servicing queues that started paused and became unpaused afterwards. Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
gpestana
left a comment
There was a problem hiding this comment.
Added a question and a suggestion wrt to the QueuePausedQuery trait, but lgtm!
| } | ||
|
|
||
| /// Provides information on paused queues. | ||
| pub trait QueuePausedQuery<Origin> { |
There was a problem hiding this comment.
Maybe we could use the frame_support::Get trait instead? The type name is explicitly enough to use the getter trait and it things readable.
|
bot merge |
* pallet-message-queue: add queue pausing Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix build Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Remove check Otherwise it would not start servicing queues that started paused and became unpaused afterwards. Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> --------- Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Introduces a
QueuePausedQueryhook into the MQ pallet that is polled once before starting to service a queue. This hook decided whether the queue should start service or not.It can be used to dynamically pause queues and is better than using
Yieldsince no PoV is wasted for loading the first message andProcessMessagedoes not need to be implemented just for pausing.Context: Greatly reduces the complexity of paritytech/cumulus#2157
I also implemented explicit suspension (via
set_suspended) by adding a bool flag to theBookStatehere. This is generally a nice thing to have for the future IMHO, but not well usable for 2157. This approach works better when knowing in advance which queues need to stay paused without any more complicated predicates involved.2157 instead has custom predicate logic here which can change at any time.
Changes:
QueuePausedQueryto the MQ pallet Config.()indicates that nothing is paused.frame_support::traits::QueuePausedQuerypallet_message_queue::ErrorandExecuteOverweightErrorPolkadot companion: paritytech/polkadot#7433