time-bound tests fail sometimes

[krakovia-evm]

I've noticed something weird with tests that depends on block.timestamp.
repo: https://github.com/krakovia-evm/VyperVestedClaims
my platform is windows11

I set the "start" timestamp when i deploy the contract, in /script/deploy.py, function deploy
in my tests (/tests/test_vested_airdrop.py) it seems that the timestamp is incremented when it reach the tests.
If i add a function inside the contract to update the timestamp, and set it as now() just before the function call, the test passes.

Also, if i run the same tests multiple times, they fail occasionally.

would be cool to have a sort of settings where we can "pin" the block.timestamp, or somehow modify how it works.

[s3bc40]

Hey 👋

Thanks for the feedback, I have checked your code quickly in the test.

I do not know if it comes to this, since I am not an expert of titanoboa, but maybe it can help.

@PatrickAlphaC maybe more titanoboa related or is it something that we can control?

---

From your code to warp, you are doing it like this:

def warp(timestamp: int):
    boa.env.evm.patch.timestamp = timestamp

It is not in their recent doc, still WIP it will come in the future I think, but you can maybe use boa.env.time_travel in your test?

https://github.com/vyperlang/titanoboa/blob/a8d5a6cd61632dbcb8f7c472974efa72decbe1b0/boa/environment.py#L368

def time_travel(
        self,
        seconds: Optional[int] = None,
        blocks: Optional[int] = None,
        block_delta: int = 12,
    ) -> None:
        if (seconds is None) == (blocks is None):
            raise ValueError("One (and only one) of seconds or blocks should be set")
        if seconds is not None:
            blocks = seconds // block_delta
        else:
            assert blocks is not None  # mypy hint
            seconds = blocks * block_delta

        self.evm.patch.timestamp += seconds
        self.evm.patch.block_number += blocks

[PatrickAlphaC]

Yeah, I think this would be a boa thing. Could you try doing what @s3bc40 suggests?

Nice work @s3bc40

[krakovia-evm]

seems it doesn't solve the issue.
Still getting inconsistent results, like in this test i jump in time 4 times, and "mox test" doesn't always fail on a single one
But yeah.. i guess it's not an issue inside moccasin, it's how boa handle the EVM time.

another run, no code touched

should i open the issue in their respective repo?

[s3bc40]

Yeah, you can do so @krakovia-evm! Keep this issue thought and link it to titanoboa. It would be great to know the solution of your issue because Mox depends on titanoboa 👍

[s3bc40]

@krakovia-evm I might have found a solution while auditing on CodeHawks contest. I'll write it inside one of my submission with a reworked version of the test and deploy part.

[s3bc40]

@krakovia-evm Here is how to avoid the error, how I "fixed" it:

1. Deploy the contract with boa env timestamp rather than datetime.

def deploy() -> VyperContract:
    current_time = int(boa.env.evm.patch.timestamp)

2. Use boa.env.time_travel instead of custom warping to take into account the block number too.

boa.env.time_travel(THIRTY_DAYS)

You can also check the code since I forked the contest: https://github.com/s3bc40/2025-02-vyper-vested-claims/tree/main

Hope this helps and that your audited contract will be helpful!

Happy coding 🐍