fix(ci): give e2e_multiple_blobs AVM check-circuit a larger timeout/CPU budget

[AztecBot]

Problem

The avm-check-circuit job failed on next (run 26784473487) with exit code 124 (timeout).

A single input timed out — e2e_multiple_blobs tx 0x17e546c9… — while every other input passed in ~4s:

FAILED ...: bb-avm avm_check_circuit ... e2e_multiple_blobs/...-0x17e546c9....bin (35s) (code: 124)
run_test_cmd '...:ISOLATE=1:TIMEOUT=30s:NAME=avm_cc_e2e_multiple_blobs_0x17e546c9 ...'

Root cause

Not a correctness bug or a hang. The e2e_multiple_blobs tx produces by far the largest AVM circuit (~700k rows). On the default isolate resources (2 CPUs, 8g), the per-input run breaks down as:

• Simulating: ~2s
• Generating trace: ~24s (CPU-bound, 2 CPUs)
• Checking circuit over 700,560 rows (peak ~3.9 GiB) — started but killed before finishing

All AVM check-circuit inputs share a single TIMEOUT=30s budget in avm_check_circuit_cmds. This input simply doesn't fit in 30s on 2 CPUs — exactly the case the existing WARNING comment in that function anticipated ("transactions could need more CPU and MEM than we allocate by default … they might start timing out").

Fix

Add a per-input override (mirroring the per-test override idiom already used in test_cmds) so the large e2e_multiple_blobs circuit gets CPUS=8:TIMEOUT=180s. More CPUs cut the CPU-bound trace generation substantially, and the longer timeout gives generous headroom for the check itself. All other small inputs keep the default TIMEOUT=30s / 2 CPUs, so overall stage parallelism is unaffected. Peak memory (~3.9 GiB) is already under the 8g default, so MEM is left unchanged.

Notes

• Targeting next as requested by the CI failure dispatch.
• This is a CI resource/timeout adjustment only; no production or circuit logic changes.

---

Created by claudebox · group: slackbot

[AztecBot]

Automatically closing this stale claudebox draft PR (no updates for 5+ days). Re-open if still needed.