Update Scheduler to have a configurable block provider #7434

[seemantaggarwal]

Follow up from #6362 (comment)

The goal of this PR is to have the scheduler pallet work on a parachain which does not produce blocks on a regular schedule, thus can use the relay chain as a block provider.

Because blocks are not produced regularly, we cannot make the assumption that block number increases monotonically, and thus have new logic to handle multiple spend periods passing between blocks.

Requirement:

instead of using the hard coded system block number. We add an associated type BlockNumberProvider

[gui1117]

Direction is good

[gui1117]

We will need a doc comment that explains this type, and warns that it must not be too much out of sync with the local block number. More precisely between every block the increment of this number should be reasonably small otherwise performance degrades will degrade a lot as it reads one storage per block number.

[seemantaggarwal]

Thanks, I will add it towards the end of the pr for sure, I will look into it. At this moment, I am not entirely sure of the value that needs to be advised, i will get more insights into it, thanks for the reminder :)

[gui1117]

We can suggest people to use the system block number or the relay chain block number (this second option, only if they expect their parachain to execute very regularly).

[seemantaggarwal]

note: this is a part of #6297

[seemantaggarwal]

This is where I am stuck atm:

error[E0277]: the trait bound <<<T as frame_system::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number: EncodeLike<<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber> is not satisfied
     --> /Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/frame/scheduler/src/lib.rs:651:36
      |
  651 | ...                   Lookup::<T>::insert(name, item);
      |                       -------------------       ^^^^ unsatisfied trait bound
      |                       |
      |                       required by a bound introduced by this call

What I have tried:

1. Convert the block number to match expected type:
   something like: let converted_number: T::BlockNumber = <T::BlockNumberProvider as BlockNumberProvider>::current_block_number().saturated_into(); Lookup::<T>::insert(name, (converted_number, some_value));
   and then something like:
   if let Some(item) = old::Lookup::<T>::take(id) { let converted_item: (u32, u32) = (item.1, item.0.into()); // Convert using .into() Lookup::<T>::insert(name, converted_item); }

2. I have also tried changing the migration functions by adding
   pub fn migrate_v2_to_v4() -> Weight where <<<T as frame_system::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number: parity_scale_codec::EncodeLike<<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber>{

Now this, makes me think I have 2 following options going ahead:

1. Implement a new migrate v4_to_v5 for lookup (I am not sure how to do that yet, but can be figured out)
2. Implement EncodeLike for BlockNumberProvider (as far as I understand this cannot be done since it is coming from codec and not a custom impl)

Would like to get some opinion/help here on the options, or if there is any another thing to try

Note: things I have tried are just a summary of the rabbit hole,if you do leave a comment here, I can try it out and answer if it works for me or not

[gui1117]

This is where I am stuck atm:

error[E0277]: the trait bound <<<T as frame_system::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number: EncodeLike<<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber> is not satisfied
     --> /Users/seemantaggarwal/RustroverProjects/polkadot-sdk/substrate/frame/scheduler/src/lib.rs:651:36
      |
  651 | ...                   Lookup::<T>::insert(name, item);
      |                       -------------------       ^^^^ unsatisfied trait bound
      |                       |
      |                       required by a bound introduced by this call

What I have tried:

1. Convert the block number to match expected type:
   something like: let converted_number: T::BlockNumber = <T::BlockNumberProvider as BlockNumberProvider>::current_block_number().saturated_into(); Lookup::<T>::insert(name, (converted_number, some_value));
   and then something like:
   if let Some(item) = old::Lookup::<T>::take(id) { let converted_item: (u32, u32) = (item.1, item.0.into()); // Convert using .into() Lookup::<T>::insert(name, converted_item); }

2. I have also tried changing the migration functions by adding
   pub fn migrate_v2_to_v4() -> Weight where <<<T as frame_system::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number: parity_scale_codec::EncodeLike<<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber>{

Now this, makes me think I have 2 following options going ahead:

1. Implement a new migrate v4_to_v5 for lookup (I am not sure how to do that yet, but can be figured out)
2. Implement EncodeLike for BlockNumberProvider (as far as I understand this cannot be done since it is coming from codec and not a custom impl)

Would like to get some opinion/help here on the options, or if there is any another thing to try

Note: things I have tried are just a summary of the rabbit hole,if you do leave a comment here, I can try it out and answer if it works for me or not

The type:

<<T as frame_system::Config>::Block as sp_runtime::traits::Block>::Header as sp_runtime::traits::Header>::Number

Doesn't implement:

EncodeLike<<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber>

Because:

<<T as pallet::Config>::BlockNumberProvider as sp_runtime::traits::BlockNumberProvider>::BlockNumber

Is a completely different type.

I think you are trying somewhere to put the system block number into storage, but the type expect the configured provided block number.

[seemantaggarwal]

Looking at the current failure it fails when running:
cargo nextest run --workspace --features runtime-benchmarks benchmark --locked --cargo-profile testnet --cargo-quiet
with the error:

Error[E0308]: mismatched types --> substrate/frame/scheduler/src/benchmarking.rs:62:40 | 62 | Pallet::<T>::do_schedule_named(name, t, period, 0, origin.clone(), call)?; | ------------------------------ ^ expected sp_runtime::traits::BlockNumberProvider::BlockNumber, found sp_runtime::traits::Header::Number| |

and other similar.
check the error here: https://github.com/paritytech/polkadot-sdk/actions/runs/13163415501/job/36737726646

I tried:
replacing the hardcoded
-const BLOCK_NUMBER: u32 = 2;
and now = BLOCK_NUMBER.into()
with

let now = max_scheduled_blocks::<T>().into();
where
fn max_scheduled_blocks<T: Config>() -> u32 { T::MaxScheduledPerBlock::get() }

[seemantaggarwal]

Reverted the last commit, as it did not really solve much, bringing it to attention of @gui1117 @ggwpez
i fixed the test too though.

#7441 (comment) -> read the comment here

[muharem]

Error[E0308]: mismatched types --> substrate/frame/scheduler/src/benchmarking.rs:62:40 | 62 | Pallet::::do_schedule_named(name, t, period, 0, origin.clone(), call)?; | ------------------------------ ^ expected sp_runtime::traits::BlockNumberProvider::BlockNumber, found sp_runtime::traits::Header::Number| |

@seemantaggarwal should be your new block number alias instead

polkadot-sdk/substrate/frame/scheduler/src/benchmarking.rs

Line 53 in f373af0

when: frame_system::pallet_prelude::BlockNumberFor<T>,

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13259626868
Failed job name: build-rustdoc

[ggwpez]

LGTM, had to push some fixes since we want to get this into the next release.

[ggwpez]

We should probably deprecate the migrations. They would not interact so well with changing the BN provider at the same time and it is a lot of legacy code

[kianenigma]

Yeah, keeping the old migrations around is an aspiration that we gave up on a while ago