Setting block timestamp not reflecting timestamp inside Fuel VM

[FossilFrank]

I’m running into the same problem @buddy-brontosaurus had here:

Is there any way to manipulate the block timestamps?

Ah thanks → I am now getting panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "Response errors; The start time must be set after the latest block time: 4611686020102744001" }', tests/harness.rs:84:80 This is weird because before I execute the code that produced blocks, I do chain_info().await.unwrap().latest_block; and that returns block number 1 and block time is None.

I can use the SDK to set block timestamps, and this works normally if I query from Rust using provider.get_blocks.

However, when I call the following code in my Sway contract:

    fn get_time() -> u64 {
        timestamp()
    }

…it returns the current time, (4611686020106380522), not the custom time that I tried to specify.

[buddy-brontosaurus]

FWIW I never found a resolution. I just created a helper timestamp method on Sway and called those from the rust sdk.
The other option is mocking your own timestamps

[maurice]

Bump
Would be highly appreciated if sb could clarify whether setting a custom timestamp is now possible or not.

[RahezJenar]

yes , its slow respond website

[iqdecay]

Hey, sorry this passed our radar. There was a problem with the way fuel-core handled block production, that was fixed here.
Progress on integrating this upstream change in the SDK is tracked here, it should be out soon.

[iqdecay]

The fix was part of https://github.com/FuelLabs/fuels-rs/pull/950, and you can find a proper example since docs: show example of block time travel by iqdecay · Pull Request #985 · FuelLabs/fuels-rs · GitHub.