Skip to content

test(e2e): pin gas_estimation public-payment txs to one block to deflake fee comparison - #24382

Merged
spalladino merged 1 commit into
merge-train/spartan-v5from
spl/deflake-gas-estimation-public-payment
Jun 30, 2026
Merged

test(e2e): pin gas_estimation public-payment txs to one block to deflake fee comparison#24382
spalladino merged 1 commit into
merge-train/spartan-v5from
spl/deflake-gas-estimation-public-payment

Conversation

@spalladino

Copy link
Copy Markdown
Contributor

Problem

The single-node/fees/gas_estimation test estimates gas with public payment method flakes (CI hash 8b1cc7ba303cf26f, FLAKED-then-retried-green on this branch). The first-attempt failure is the fee comparison at line 200:

expect(received).toBeLessThan(expected)
Expected: < 1044344170000000n
Received:   4341054744900000n

Root cause (grounded in logs + source)

The test sends two token-transfer txs concurrently via sendTransfers: withEstimate uses tight estimated teardown gas limits, withoutEstimate uses the large default limits. It expects withEstimate to pay less, because unused teardown gas is not refunded. transactionFee scales with the landing block's feePerL2Gas.

Under the pipelining preset (minTxsPerBlock: 0, two blocks per slot) the two txs are not pinned to a block, so they land in different blocks:

  • withEstimate (0x1a3c0ed…, billed l2Gas=979281) -> block 18, feePerL2Gas=4432900000 -> txFee=4341054744900000 (the failing Received).
  • withoutEstimate (0x0461a777…, billed l2Gas=1702550) -> block 19, feePerL2Gas=613400000 -> txFee=1044344170000000 (the Expected < bound).

On a freshly-deployed chain the L1 base fee steps down across checkpoint boundaries (here l1BaseFee 10721937 -> 1462645, with congestionCost=0 and ethPerFeeAsset constant), so the two blocks' feePerL2Gas differ ~7.2x. That price gap swamps the teardown-refund difference and flips the comparison. A passing run had the same tx split but a flat price across the boundary, so it held by luck. The L2 gas price derives from l1BaseFee in sequencer-client/src/global_variable_builder/fee_predictor.ts (computeManaMinFee).

Fix

Mirror the sibling estimates gas with Fee Juice payment method test in the same file: set minTxsPerBlock: 2, maxTxsPerBlock: 2 and wait for the sequencer to go idle before sending, so both txs land in the same block and share one feePerL2Gas. This isolates the teardown-refund difference the test actually verifies.

  • No behavioral assertion is relaxed or removed.
  • The sibling's totalManaUsed === gasLimits.l2Gas * 2 assertion is deliberately not copied: the two public-payment txs bill different mana by design.
  • Added an explicit expect(withEstimate.blockNumber).toEqual(withoutEstimate.blockNumber) so a future batching regression fails clearly rather than resurfacing as a fee-comparison flake.

Verification

  • yarn build passes (whole project).
  • Red/green could not be reproduced locally: the failure requires the L1-base-fee step to fall between the two tx blocks, which is nondeterministic startup timing (the passing run shows it depends on chance). The green direction is structurally guaranteed by the same-block pin and is the same idiom the non-flaky Fee Juice sibling already uses; the assertion arithmetic was verified to hold at every observed feePerL2Gas.

…ake fee comparison

The "estimates gas with public payment method" test sends two token-transfer txs
concurrently (one with estimated teardown gas limits, one with the large defaults)
and asserts the estimated tx pays a lower fee, since unused teardown gas is not
refunded. Under the pipelining preset (minTxsPerBlock: 0, two blocks per slot) the
two txs can land in different blocks, and transactionFee scales with that block's
feePerL2Gas. On a freshly-deployed chain the L1 base fee steps down across checkpoint
boundaries, so the two blocks can have feePerL2Gas differing several-fold (observed
4432900000 vs 613400000, ~7.2x). That price gap swamps the teardown-refund difference
and flips the comparison: the estimated tx landed in the higher-priced block and paid
more, failing `toBeLessThan`. A passing run had the same tx split but a flat price, so
it held by luck.

Mirror the sibling Fee Juice test: set minTxsPerBlock/maxTxsPerBlock to 2 and wait for
the sequencer to go idle before sending, so both txs land in the same block and share
one feePerL2Gas. This isolates the teardown-refund difference the test means to verify.
No behavioral assertion is relaxed; an explicit same-block assertion guards the
invariant so a future batching regression fails clearly rather than as a fee flake.
@spalladino
spalladino merged commit d781af3 into merge-train/spartan-v5 Jun 30, 2026
26 checks passed
@spalladino
spalladino deleted the spl/deflake-gas-estimation-public-payment branch June 30, 2026 08:33
rangozd pushed a commit to rangozd/aztec-packages that referenced this pull request Aug 5, 2026
BEGIN_COMMIT_OVERRIDE
refactor(e2e): relocate no-node straggler tests (AztecProtocol#24344)
test(e2e): pin gas_estimation public-payment txs to one block to deflake
fee comparison (AztecProtocol#24382)
feat(archiver): event-trigger L2BlockStream sync from archiver updates
(AztecProtocol#24317)
test(e2e): speed up individual e2e tests (AztecProtocol#24345)
chore(e2e): warm blob KZGs in parallel during setup (AztecProtocol#24383)
chore: add perf as a valid PR title prefix (AztecProtocol#24412)
test(e2e): adopt shared wait helpers (AztecProtocol#24404)
test(e2e): run prover client.test.ts in CI (AztecProtocol#24399)
fix(ethereum): mine empty L1 blocks without touching the mempool
(AztecProtocol#24414)
test(e2e): deflake empty block proving test (AztecProtocol#24411)
test(e2e): allocate HA node p2p ports above the ephemeral range to
deflake e2e_ha_full (AztecProtocol#24418)
fix(sequencer): use evmMine in automine auto-settle to avoid dropping
test L1 txs (AztecProtocol#24421)
test(e2e): instrument common spans for wall-clock tracking (AztecProtocol#24407)
test(e2e): remove redundant reqresp_no_handshake e2e test (AztecProtocol#24424)
END_COMMIT_OVERRIDE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants