-
Notifications
You must be signed in to change notification settings - Fork 2.6k
pallet-message-queue
: add queue pausing
#14318
Conversation
Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
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.
Seem harmless enough, but what about migrations?
Its not changing any storage - just adding a |
@@ -220,3 +230,15 @@ where | |||
E::footprint(O::get()) | |||
} | |||
} | |||
|
|||
/// Provides information on paused queues. | |||
pub trait QueuePausedQuery<Origin> { |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
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>
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.
Added a question and a suggestion wrt to the QueuePausedQuery
trait, but lgtm!
@@ -220,3 +230,15 @@ where | |||
E::footprint(O::get()) | |||
} | |||
} | |||
|
|||
/// Provides information on paused queues. | |||
pub trait QueuePausedQuery<Origin> { |
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 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
QueuePausedQuery
hook 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
Yield
since no PoV is wasted for loading the first message andProcessMessage
does 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 theBookState
here. 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:
QueuePausedQuery
to the MQ pallet Config.()
indicates that nothing is paused.frame_support::traits::QueuePausedQuery
pallet_message_queue::Error
andExecuteOverweightError
Polkadot companion: paritytech/polkadot#7433