Skip to content

fix(tests): stop test_tx_gas_limit opting into an inclusion-list variant - #3503

Draft
Marchhill wants to merge 1 commit into
ethereum:eips/amsterdam/eip-7805from
Marchhill:fix/il-variant-tx-gas-limit-floor
Draft

fix(tests): stop test_tx_gas_limit opting into an inclusion-list variant#3503
Marchhill wants to merge 1 commit into
ethereum:eips/amsterdam/eip-7805from
Marchhill:fix/il-variant-tx-gas-limit-floor

Conversation

@Marchhill

Copy link
Copy Markdown
Contributor

What

test_tx_gas_limit no longer opts into the inclusion-list variant.

Why

The test pins the block gas limit to the smallest value that makes its point — the transaction asks for 21,001 and the block allows 21,000, so it is rejected for exceeding the allowance:

tx = Transaction(gas_limit=21001, ..., error=TransactionException.GAS_ALLOWANCE_EXCEEDED)
env.gas_limit = ZeroPaddedHexNumber(21000)

The inclusion-list variant moves that transaction out of the block, leaving an empty block that still carries the 21,000 gas limit. A block's access list may hold at most block_gas_limit / 2000 items, and the mandatory system-contract items alone exceed what 21,000 allows, so the variant asks for VALID on a block no client can accept:

engine_newPayloadV6 returned INVALID, expected VALID.
ValidationError: BlockAccessListGasLimitExceeded: BAL has 25 items,
exceeds limit of 10 (block_gas_limit / 2000)

25 mandatory items need a gas limit of at least 50,000, which is what test_bal_gas_limit_boundary establishes — so the fixture contradicts a sibling test rather than expressing a client disagreement.

The variant is unfillable-as-expected for any consumer, which is why it is currently carried as a known failure downstream rather than gating anything.

Why removing the marker rather than raising the limit

Raising both values (say 100,001 against 100,000) would keep the plain test's meaning and clear the floor, but it rewrites a long-standing frontier fixture for every fork to fix a variant that only exists on one, and the minimal pair is part of what the test documents.

No coverage is lost either way. The scenario the variant would have exercised — an inclusion-list transaction that cannot be included does not make the block non-compliant — is covered purpose-built by test_block_with_failing_included_il_tx_is_valid in tests/bogota/eip7805_focil/, across nine scenarios.

Verification

tests/frontier/validation/test_transaction.py collects 14 tests unchanged, and ruff check / ruff format --check are clean. InclusionListVariantFixtureFormat.discard_fixture_format_by_marks drops the variant when the marker is absent, so this removes the inclusion-list fixtures for this test and leaves its other formats untouched.

I could not re-fill Bogota fixtures locally, so the error above is from the released tests-focil-devnet@v0.2.0 archive rather than from regenerated output.

@fselmo fselmo added this to the FOCIL milestone Sep 2, 2026
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.

2 participants