`Warning: Found unknown `assert_all` config key in section `invariant` defined in foundry.toml.`

[pcaversaccio]

PR #12587 introduced assert_all as config key for invariant tests. In snekmate I have the following:

invariant = { runs = 256, depth = 15, assert_all = false }

However, any forge command triggers a warning now:

Warning: Found unknown `assert_all` config key in section `invariant` defined in foundry.toml.

I use latest nightly for testing:

[pcaversaccio]

there is something weird going on:

invariant tests are not run anymore in my gas snapshots: https://github.com/pcaversaccio/snekmate/pull/376/changes#diff-11538116afca6cc6a316ec7e5532f95ee5b404085a676b3d186ac5776ef99712

what is happening?

changes in Foundry version:

[pcaversaccio]

might be related to this PR #14844? so assert_all is removed again? what should I do in snekmate now to preserve the original behaviour and why does foundry omit invariant tests in my gas snapshot?

[mablr]

Thanks for reporting @pcaversaccio, I think you're right this is related to #14844.

assert_all was introduced in #12587 for the previous invariant execution model.

As far as I understand, #14844 changed compatible boolean invariants to run as one contract-level campaign, where the selected predicates are evaluated together. With that model, assert_all became redundant and was removed. So in snekmate I think you can simply remove assert_all = false. @0xKarl98 correct me if i'm wrong ;)

[mablr]

The gas snapshot diff looks like a #14844 reporting side effect: forge snapshot emits only the merged campaign’s anchor row. The other predicates should still run, but aren’t expanded into .gas-snapshot rows yet.

[pcaversaccio]

The other predicates should still run, but aren’t expanded into .gas-snapshot rows yet.

Is this a regression?

[mablr]

Yes I think so, I made a smol fix #14990 specifically for this.

Tested against snekmate, it seems to restore snapshot we had before #14844.

[pcaversaccio]

so let me see if I got it right; before #14844: each invariant test function was fuzzed independently. Now: all invariant functions in a contract are fuzzed together as a single campaign. Correct?

[mablr]

Now: all invariant functions in a contract are fuzzed together as a single campaign. Correct?

Yes, for all compatible boolean invariants.

[pcaversaccio]

compatible boolean invariants.

what are non-compatible boolean invariants?

[mablr]

In the sense of #14844, “compatible” mean invariants with the same resolved invariant config, so they can be run together as you stated earlier. When their config differs (eg w/ forge-config inline override) they are still run separately (non-compatible).

[pcaversaccio]

In the sense of #14844, “compatible” mean invariants with the same resolved invariant config, so they can be run together as you stated earlier. When their config differs (eg w/ forge-config inline override) they are still run separately (non-compatible).

right - and what happens for non-Boolean invariants? I mean those invariant tests should also be run?