Block number in the benchmark code is 0, but is 1 in the running code

Question

If I'm running a benchmark and I get the current block number from inside the benchmark code (i.e. in the setup before I actually call the call I'm trying to benchmark) using frame_system::Pallet::<T>::block_number() the block number I get is 0.

Then within call I'm trying to benchmark I get a block number of 1.

I'm assuming the benchmark setup code is run like / after genesis, in block 0, and then the chain progresses to 1 for the calls?

Not exactly clear why this is the case if I haven't told it to progress, especially because you do have to explicitly tell the TestExternalities in a test that you are at block 1.

Answer 1

Your observation is correct that the block number is being set to 1 if it is 0 between the setup and call phase. This is confusing and should be improved, I opened substrate #12559 for that.

The current safe way of doing it is to always set the block-number in the setup phase of the benchmarks to something non-zero. Eg:

block_does_not_change {
    frame_system::Pallet::<T>::set_block_number(2u32.into());
}: {
    assert_eq!(frame_system::Pallet::<T>::block_number(), 2u32.into());
}

In this case it will not be modified.