Make it possible and easy to manipulate next block's block_timestamp

[Nradko]

Some contracts must be tested in an e2e environment (using substrate-contract-node) with the possibility of testing their time-dependent behavior. To make such tests possible one should be able to manipulate the next block's block_timestamps. It would be great if such manipulation could be done using polkadot.js.
Currently, it is not possible to set a block_timestamp of the next block. The issue is to add such a functionality.

[Nradko]

Hey @cmichi @pgherveou, is it possible to add such functionality?

[Nradko]

@pgherveou up!

[pgherveou]

Sorry for the slow reply will look into options when i get a chance next week

[pgherveou]

mmm I guess we could do that by exposing a subxt client to call sudo::timestamp::now

Not sure it fits your use case, but with drink! you can do something like this

    #[drink::test]
    fn some_test() -> Result<(), Box<dyn Error>> {
        let contract = BundleProvider::local()?;
        let mut session = Session::<MinimalRuntime>::new()?
            .deploy_bundle_and(contract, "new", &["true"], vec![], None)?;

       // manipulate timestamp
        session.sandbox().set_timestamp(1);

       // do more testing
       
      Ok(())
    }

[Nradko]

Hey @pgherveou,

we have managed to modify the pallet timestamp and use it in the contract node. Check it here: https://github.com/WookashWackomy/custom-substrate-contracts-node/tree/contracts-node-custom-timestamp-pallet.

In the shared repo, a new storage field to pallet-timestamp "fake_time" was added. "fake_time" may be set with a "set_time" call. If "fake_time" != 0 then it is used instead of the real time.

It would be beneficial for every developer to add something similar to this repo. The question is how to manage the timestamp.
Maybe we should have calls "freeze_time", "unfreeze_time", "increase_time", "decrease_time", and "set_time".

There is one problem we don't know how to solve yet. Namely, when the node is restarted with '--base-path' argument, it should restart with the state that was previously saved at the path. The state of contracts is restored properly but the state of pallet_timestamp storage is not...

[Nradko]

@pgherveou up, what do you think about the above?

[pgherveou]

A few questions:

• why is calling the unmodified set_time with a static value not sufficient for your tests?
• Might be easier to provide your own pallet that implement the Time trait, instead of modifying the existing one

[Nradko]

Ad 1) we need to be able to modify time in e2e enviroment, not in drink enviroment.
Ad 2) Might be.