-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Referendum decision period quantization #12810
Conversation
@@ -754,9 +759,6 @@ impl<T: Config<I>, I: 'static> Pallet<T, I> { | |||
call: BoundedCallOf<T, I>, | |||
when: T::BlockNumber, | |||
) -> Option<(T::BlockNumber, ScheduleAddressOf<T, I>)> { | |||
let alarm_interval = T::AlarmInterval::get().max(One::one()); | |||
let when = when.saturating_add(alarm_interval).saturating_sub(One::one()) / | |||
(alarm_interval.saturating_mul(alarm_interval)).max(One::one()); |
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.
its probably supposed to be calculated from the duration.
I moved this logic to decision_alarm, because we need the quantization only for the decision period.
The preparation and confirmation period has to pass fully for each stage, at least this how I understand it.
The CI pipeline was cancelled due to failure one of the required jobs. |
/// Minimum alarm period for the referendum wakeup scheduler during the decision stage. | ||
/// Prevents wake up calls from being too frequent as a result of the quantization. | ||
#[pallet::constant] | ||
type MinAlarmPeriod: Get<Self::BlockNumber>; |
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.
What's the actual use-case for this?
Please add a test. |
Please see #12815 and check if it passes your test. |
Closing in favor of this pr #12815 |
Right now if
AlarmInterval
set to > 1, the time for alarm will be calculated to the past, and scheduler will fail.This PR fixes it.