test(ci): drop e2e_kernelless_simulation from backwards-compat e2e#22999
Merged
benesjan merged 1 commit intobackport-to-v4-next-stagingfrom May 6, 2026
Merged
Conversation
AztecBot
added
ci-draft
benesjan
approved these changes
May 6, 2026
benesjan
added
the
ci-compat-e2e
benesjan
pushed a commit
that referenced
this pull request
May 6, 2026
…23005) ## Summary Forward port of #22999 (which targets `backport-to-v4-next-staging`) onto `merge-train/fairies` so the v4 and v5 versions of `compat_test_cmds` stay aligned. Excludes `src/e2e_kernelless_simulation.test.ts` from the `compat_test_cmds` set in `yarn-project/end-to-end/bootstrap.sh`, so it no longer runs under the backwards-compatibility (`ci-compat-e2e`) job. ## Why `e2e_kernelless_simulation` asserts on the exact number of nullifiers emitted by the test contracts. PR #22939 changed the contract artifacts and now emits a different nullifier count, which causes the test to fail when the new client runs against older contract artifacts in compat mode (failing v4 nightly: https://github.com/AztecProtocol/aztec-packages/actions/runs/25419116073/job/74558302821#step:4:38). The mismatch is not a real backwards-compat regression — the test is asserting on internal accounting that legitimately changes between versions. Per @benesjan and @mverzilli, the right call is to drop this test from the compat matrix rather than maintain compat-aware nullifier-count assertions; reducing the compat surface to tests that actually exercise the contract API is the longer-term direction. Forward-porting here keeps the v5 compat matrix in lockstep with v4. ## Implementation Identical to #22999: add `kernelless_simulation` to the bash extglob exclusion list for the top-level `e2e_*.test.ts` pattern. ```diff - src/e2e_!(block_building|prover_*).test.ts + src/e2e_!(block_building|prover_*|kernelless_simulation).test.ts ``` Comment block above the function updated with the same reasoning. Verified with `shopt -s extglob` that the new pattern excludes only `src/e2e_kernelless_simulation.test.ts` and still includes every other top-level `src/e2e_*.test.ts`. ClaudeBox log: https://claudebox.work/s/ed6536a05f7d2b77?run=4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Excludes
src/e2e_kernelless_simulation.test.tsfrom thecompat_test_cmdsset inyarn-project/end-to-end/bootstrap.sh, so it no longer runs under the backwards-compatibility (ci-compat-e2e) job.Why
e2e_kernelless_simulationasserts on the exact number of nullifiers emitted by the test contracts. PR #22939 changed the contract artifacts and now emits a different nullifier count, which causes the test to fail when the new client runs against older contract artifacts in compat mode (see the failingci-compat-e2estep onv4.3.0-nightly.20260506: https://github.com/AztecProtocol/aztec-packages/actions/runs/25419116073/job/74558302821#step:4:38). The mismatch is not a real backwards-compat regression, just an artifact of the test asserting on internal accounting that legitimately changes between versions.Per @benesjan and @mverzilli, the right call is to drop this test from the compat matrix rather than maintain compat-aware nullifier-count assertions; reducing the compat surface to tests that actually exercise the contract API is the longer-term direction.
Implementation
Added
kernelless_simulationto the bash extglob exclusion list for the top-levele2e_*.test.tspattern:Verified the new pattern with
shopt -s extgloblocally —e2e_kernelless_simulation.test.tsis no longer matched, all other top-level e2e tests still are. Comment block above the function updated to record the reason.Note: the underlying release publish path (
InvalidAccessKeyId/ec2:RunInstances) tracked in https://gist.github.com/AztecBot/da1ac0bbfaae2564fe90c993b2886590 is not addressed by this PR — it requires theAWS_SESSION_TOKENforward inbootstrap_ec2and an IAM policy change. This change just stopsci-compat-e2efrom being red on nightlies due to the kernelless_simulation flake.ClaudeBox log: https://claudebox.work/s/ed6536a05f7d2b77?run=3