Fixture Error Bug

[petdomaa100]

Version of Hardhat

2.22.5

What happened?

Hey, thanks for looking over my issue.

I have a few contracts in my protocol. Two of them are token contracts that have a shared interface and some unique functions. The shared functions have different implementations but the logic for testing them is the same. Because of this, I set up tests that can be ran for both tokens.

Unfortunately, I ran into an odd FixtureSnapshotError even though I am not using any beforeEach or nested fixtures.

Minimal reproduction steps

https://github.com/petdomaa100/hardhat-fixture-error-minimal-reproducible-example

Search terms

fixture, FixtureSnapshotError

[galargh]

That's because the deployed contracts differ from the ones returned by the fixture set up function. What you could do instead is to move the call to the loadFixture to your helper functions.

So your baseTokenFixture would become something like:

async function loadBaseTokenFixture(whichOne: 'ONE' | 'TWO') {
	const fixture = await loadFixture(deployFixture); // Note the call to load fixture here
...

And then your shared test could just await that instead:

...
	it('Test 1', async () => {
		const {
			contracts: { Token }
		} = await loadBaseTokenFixture(whichOne);

		// [...] Some test
	});
...

[petdomaa100]

Hey, thanks for your suggestion it worked perfectly. :)

Could you give a quick explanation of why the error is thrown if the fixture returns different values?

[galargh]

It's not really about the return values. More so about the fixture load order. Let me get you a full explanation here.

Firstly, here is a little bit of context on the loadFixture. The way it works is it either executes the code of the fixture and then takes a snapshot of the state or finds a snapshot that has been taken before and restores it.

I noticed you were using an outdated version of hardhat and, more importantly, network helpers. v1.0.0 of the latter to be exact.

In that version of network helpers, loadFixture would restore a snapshot as long as it has been previously taken. See

hardhat/packages/hardhat-network-helpers/src/loadFixture.ts

Line 36 in 522c984

await snapshot.restorer.restore();

Unfortunately, that is a wrong behaviour, which your example showcases.

There, we:

1. Load base fixture -> we execute the code -> snapshot A is taken
2. Load mint fixture -> we execute the code (note that we redeploy the base contracts here, too) -> snapshot B is taken
3. Load base fixture -> we restore snapshot A (note that this moves us to a point in time where snapshot B has not been taken yet)
4. Load mint fixture -> we try to restore snapshot B because it was taken before, but we fail because snapshot B is newer than where we're currently at

This has been addressed in the latest version of hardhat/network helpers. Now, if we restore a particular snapshot, all the newer ones are evicted from memory. So in your example, the timeline would be as follows:

1. Load base fixture -> we execute the code -> snapshot A is taken
2. Load mint fixture -> we execute the code -> snapshot B is taken
3. Load base fixture -> we restore snapshot A
4. Load mint fixture -> we execute the code -> snapshot C is taken

So now it works as expected, but this approach is still not as effective as it could be. Any time we load mint fixture, the underlying contracts are being redeployed and a new snapshot is taken. See https://github.com/NomicFoundation/hardhat/blob/main/packages/hardhat-network-helpers/src/loadFixture.ts#L47

To address this, my suggestion from the previous comment still stands. If you treat the underlying deployment of the contracts as a fixture, then that deployment would get executed only once, and all the subsequent tests would simply restore that deployment snapshot. But first and foremost, I would suggest updating to the latest version of hardhat and hardhat-toolbox-viem.

I hope this helps :) I'm going to close this issue now as it has been resolved.

[petdomaa100]

Thanks for your detailed explanation, it makes sense. I applied your suggestions. :)