## Summary

Enables the hive *warm-daemon client pool* on the `test-hive-eest.yml`
workflow.

The pool keeps client containers running across tests and resets chain
state via JSON-RPC `debug_setHead(0)` between them, instead of creating
a fresh container per test. On corpora with high pre-state reuse this
skips ~1.9 s of per-test overhead (`docker create` + tar upload +
`erigon init` + daemon boot).

**Effect on the hive-eest merge-queue gate:**

| Shard | `pool.size` | Baseline wall | New wall | Δ |
|---|---|---|---|---|
| cancun | 4 | 52.2 min | **18.0 min** | **−65.5%** |
| prague | 4 | 61.0 min | **22.4 min** | **−63.4%** |
| osaka | 4 | 63.0 min | **23.6 min** | **−62.6%** |
| glamsterdam-devnet | 24 | 8.5 min | 6.5 min | −22.9% |
| paris+shanghai | 0 | 13.5 min | 12.3 min | ~baseline |
| consume-rlp | 0 | 32.3 min | 31.1 min | ~baseline |

Pacemaker: **63 min → 24 min** (the gate is now 2.7× faster on every PR
/ merge group). Baseline run
[#24827222279](https://github.com/erigontech/erigon/actions/runs/24827222279);
current run
[#24941388548](https://github.com/erigontech/erigon/actions/runs/24941388548).

## Per-shard `pool.size`

The pool only helps where tests share pre-state. From a
trace-instrumented run + offline LRU simulation, the EEST access pattern
is *depth-2 consecutive*: each pre-state is hit twice in a row, then
never seen again. So `pool.size = 4` captures all available reuse on the
long consume-engine shards; bigger caches buy nothing. The other extreme
— paris+shanghai and consume-rlp — has ~unique pre-state per test (~0%
hit at any cache size) and gets `pool.size = 0`, which short-circuits
every new code path in hive (byte-identical to the pre-pool flow).

| Shard | Reuse | `pool.size` |
|---|---|---|
| cancun, prague, osaka | ~2× | 4 |
| glamsterdam-devnet | curve still climbs at 24 | 24 |
| paris+shanghai, consume-rlp | ~1× | 0 (pool disabled) |

## Files

- `.github/workflows/test-hive-eest.yml`:
- Pinned hive checkout to `erigontech/hive @
06b9774991053bf4952c98750c53fc52bceb3991` — see "Pre-merge" below.
  - Added `pool-size` per matrix entry.
- Added `--client.pool.size=${{ matrix.pool-size }}` to the hive
invocation.

No other files touched.

## Pre-merge

The hive-side change is up as a draft at
[ethereum/hive#1449](ethereum/hive#1449). This
Erigon PR currently pins the hive checkout at the corresponding
`erigontech/hive` branch, which is fine for the trial dispatches but
**not for merge**.

Before this lands:
1. ethereum/hive#1449 merges.
2. `hive-versions.json` gets a routine bump to the new ethereum/hive
ref.
3. The `repository:` / `ref:` override in `test-hive-eest.yml` is
reverted to the existing `ethereum/hive` +
`steps.hive-version.outputs.ref` pattern.
4. The `pool-size` matrix var and `--client.pool.size` flag stay —
they're the actual change this PR ships.

I'll squash the experiment commits down to that final shape once erigontech#1449
is in.

## Test plan

- [x] All 6 shards green on the bare-metal `hive` runner group across
multiple dispatches.
- [x] Per-shard `pool.size` derived from a trace-instrumented run and an
offline LRU simulator (the curve plateaus past 4 on long shards).
- [x] Low-reuse shards (paris+shanghai, consume-rlp) verified at
`pool.size=0` — wall time matches the no-pool baseline (no regression
from the pool's per-test reset overhead).
- [x] No container-count / disk-pressure issues on the runner (global
LRU cap bounds the running daemon count regardless of test corpus).

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

## Summary

Enables the hive *warm-daemon client pool* on the `test-hive-eest.yml`
workflow.

The pool keeps client containers running across tests and resets chain
state via JSON-RPC `debug_setHead(0)` between them, instead of creating
a fresh container per test. On corpora with high pre-state reuse this
skips ~1.9 s of per-test overhead (`docker create` + tar upload +
`erigon init` + daemon boot).

**Effect on the hive-eest merge-queue gate:**

| Shard | `pool.size` | Baseline wall | New wall | Δ |
|---|---|---|---|---|
| cancun | 4 | 52.2 min | **18.0 min** | **−65.5%** |
| prague | 4 | 61.0 min | **22.4 min** | **−63.4%** |
| osaka | 4 | 63.0 min | **23.6 min** | **−62.6%** |
| glamsterdam-devnet | 24 | 8.5 min | 6.5 min | −22.9% |
| paris+shanghai | 0 | 13.5 min | 12.3 min | ~baseline |
| consume-rlp | 0 | 32.3 min | 31.1 min | ~baseline |

Pacemaker: **63 min → 24 min** (the gate is now 2.7× faster on every PR
/ merge group). Baseline run
[#24827222279](https://github.com/erigontech/erigon/actions/runs/24827222279);
current run
[#24941388548](https://github.com/erigontech/erigon/actions/runs/24941388548).

## Per-shard `pool.size`

The pool only helps where tests share pre-state. From a
trace-instrumented run + offline LRU simulation, the EEST access pattern
is *depth-2 consecutive*: each pre-state is hit twice in a row, then
never seen again. So `pool.size = 4` captures all available reuse on the
long consume-engine shards; bigger caches buy nothing. The other extreme
— paris+shanghai and consume-rlp — has ~unique pre-state per test (~0%
hit at any cache size) and gets `pool.size = 0`, which short-circuits
every new code path in hive (byte-identical to the pre-pool flow).

| Shard | Reuse | `pool.size` |
|---|---|---|
| cancun, prague, osaka | ~2× | 4 |
| glamsterdam-devnet | curve still climbs at 24 | 24 |
| paris+shanghai, consume-rlp | ~1× | 0 (pool disabled) |

## Files

- `.github/workflows/test-hive-eest.yml`:
- Pinned hive checkout to `erigontech/hive @
06b9774991053bf4952c98750c53fc52bceb3991` — see "Pre-merge" below.
  - Added `pool-size` per matrix entry.
- Added `--client.pool.size=${{ matrix.pool-size }}` to the hive
invocation.

No other files touched.

## Pre-merge

The hive-side change is up as a draft at
[ethereum/hive#1449](ethereum/hive#1449). This
Erigon PR currently pins the hive checkout at the corresponding
`erigontech/hive` branch, which is fine for the trial dispatches but
**not for merge**.

Before this lands:
1. ethereum/hive#1449 merges.
2. `hive-versions.json` gets a routine bump to the new ethereum/hive
ref.
3. The `repository:` / `ref:` override in `test-hive-eest.yml` is
reverted to the existing `ethereum/hive` +
`steps.hive-version.outputs.ref` pattern.
4. The `pool-size` matrix var and `--client.pool.size` flag stay —
they're the actual change this PR ships.

I'll squash the experiment commits down to that final shape once erigontech#1449
is in.

## Test plan

- [x] All 6 shards green on the bare-metal `hive` runner group across
multiple dispatches.
- [x] Per-shard `pool.size` derived from a trace-instrumented run and an
offline LRU simulator (the curve plateaus past 4 on long shards).
- [x] Low-reuse shards (paris+shanghai, consume-rlp) verified at
`pool.size=0` — wall time matches the no-pool baseline (no regression
from the pool's per-test reset overhead).
- [x] No container-count / disk-pressure issues on the runner (global
LRU cap bounds the running daemon count regardless of test corpus).

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

## Summary

Enables the hive *warm-daemon client pool* on the `test-hive-eest.yml`
workflow.

The pool keeps client containers running across tests and resets chain
state via JSON-RPC `debug_setHead(0)` between them, instead of creating
a fresh container per test. On corpora with high pre-state reuse this
skips ~1.9 s of per-test overhead (`docker create` + tar upload +
`erigon init` + daemon boot).

**Effect on the hive-eest merge-queue gate:**

| Shard | `pool.size` | Baseline wall | New wall | Δ |
|---|---|---|---|---|
| cancun | 4 | 52.2 min | **18.0 min** | **−65.5%** |
| prague | 4 | 61.0 min | **22.4 min** | **−63.4%** |
| osaka | 4 | 63.0 min | **23.6 min** | **−62.6%** |
| glamsterdam-devnet | 24 | 8.5 min | 6.5 min | −22.9% |
| paris+shanghai | 0 | 13.5 min | 12.3 min | ~baseline |
| consume-rlp | 0 | 32.3 min | 31.1 min | ~baseline |

Pacemaker: **63 min → 24 min** (the gate is now 2.7× faster on every PR
/ merge group). Baseline run
[#24827222279](https://github.com/erigontech/erigon/actions/runs/24827222279);
current run
[#24941388548](https://github.com/erigontech/erigon/actions/runs/24941388548).

## Per-shard `pool.size`

The pool only helps where tests share pre-state. From a
trace-instrumented run + offline LRU simulation, the EEST access pattern
is *depth-2 consecutive*: each pre-state is hit twice in a row, then
never seen again. So `pool.size = 4` captures all available reuse on the
long consume-engine shards; bigger caches buy nothing. The other extreme
— paris+shanghai and consume-rlp — has ~unique pre-state per test (~0%
hit at any cache size) and gets `pool.size = 0`, which short-circuits
every new code path in hive (byte-identical to the pre-pool flow).

| Shard | Reuse | `pool.size` |
|---|---|---|
| cancun, prague, osaka | ~2× | 4 |
| glamsterdam-devnet | curve still climbs at 24 | 24 |
| paris+shanghai, consume-rlp | ~1× | 0 (pool disabled) |

## Files

- `.github/workflows/test-hive-eest.yml`:
- Pinned hive checkout to `erigontech/hive @
06b9774991053bf4952c98750c53fc52bceb3991` — see "Pre-merge" below.
  - Added `pool-size` per matrix entry.
- Added `--client.pool.size=${{ matrix.pool-size }}` to the hive
invocation.

No other files touched.

## Pre-merge

The hive-side change is up as a draft at
[ethereum/hive#1449](ethereum/hive#1449). This
Erigon PR currently pins the hive checkout at the corresponding
`erigontech/hive` branch, which is fine for the trial dispatches but
**not for merge**.

Before this lands:
1. ethereum/hive#1449 merges.
2. `hive-versions.json` gets a routine bump to the new ethereum/hive
ref.
3. The `repository:` / `ref:` override in `test-hive-eest.yml` is
reverted to the existing `ethereum/hive` +
`steps.hive-version.outputs.ref` pattern.
4. The `pool-size` matrix var and `--client.pool.size` flag stay —
they're the actual change this PR ships.

I'll squash the experiment commits down to that final shape once #1449
is in.

## Test plan

- [x] All 6 shards green on the bare-metal `hive` runner group across
multiple dispatches.
- [x] Per-shard `pool.size` derived from a trace-instrumented run and an
offline LRU simulator (the curve plateaus past 4 on long shards).
- [x] Low-reuse shards (paris+shanghai, consume-rlp) verified at
`pool.size=0` — wall time matches the no-pool baseline (no regression
from the pool's per-test reset overhead).
- [x] No container-count / disk-pressure issues on the runner (global
LRU cap bounds the running daemon count regardless of test corpus).

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…t-circuit (erigontech#21362)

Resolves erigontech#21363. Likely also resolves Mode A (the `"previously known bad
block"` cache short-circuit) of erigontech#21364 — leaving that issue open until
verified in-tree across all its parametrizations.

## Summary

- When `engine_newPayload` short-circuits via the `badHeaders` LRU on a
previously-rejected block hash, replay the original `validationErr`
string (e.g. `"max initcode size exceeded"`) instead of the generic
`"previously known bad block"`.
- For parent-inheritance hits, wrap as `"ancestor 0x… rejected: <parent
err>"` so the cause is still traceable when the child hash hadn't been
seen on its own before.
- Falls back to the current `"previously known bad block"` string when
the cache entry has no recorded error (sync-time downloader path,
`"invalid block number"` header check before first cache-populate).
- Shrink the `badHeaders` LRU capacity from 10_000 → 96. Each entry now
holds a heap-allocated error string (not GC'd while cached); the
realistic working set for newPayload bad blocks is in the single digits
per session, so 96 leaves substantial headroom while keeping memory
well-bounded.

## Motivation

Harmless in production until the hive warm-daemon client pool (erigontech#20812)
started reusing erigon processes across EEST tests. The pool calls
`debug_setHead(0)` between tests but does not clear in-memory caches
(the pool doc-comment in `internal/libhive/pool.go` calls this out). A
later EEST test that happens to submit a payload with a block-hash also
produced by an earlier test on the same warm daemon hits the
short-circuit and gets the generic string in `validationError` — EEST's
`ErigonExceptionMapper` has no rule for it, so the test fails with the
wrong exception even though the block was correctly rejected on first
sight.

Concretely: `hive-eest / test-hive-eest (glamsterdam-devnet)`
intermittently failed with 3-4 failures over the `max-failures: 2`
budget. Two of those failures are deterministic (the documented
wrong-EEST-expectation `test_fork_transition` pair). The flaky 1-2
extras rotated across runs between variants of
`test_max_initcode_size[over_max]` and
`test_bal_invalid_extraneous_entries[*]` — exactly the pattern you'd
expect from an LRU-pool-assignment race on top of a process-lifetime
cache. See the [project memory
writeup](https://github.com/erigontech/erigon/actions/runs/26233342007/job/77199556910)
for the detailed trace.

This also makes Engine API replies more informative for legitimate
retries — a CL resubmitting after a config change / debugger session /
network glitch now gets the same actionable error twice instead of a
generic short-circuit on retry.

## Test plan

- [ ] `make lint` clean (verified locally, 3 passes)
- [ ] `make erigon integration` clean (verified locally)
- [ ] `go test ./execution/engineapi/... -short` clean (verified locally
— includes new unit tests pinning Report/IsBadHeader round-trip in
`block_downloader_test.go`)
- [ ] `hive-eest / test-hive-eest (glamsterdam-devnet)` passes on the
merge queue without the flaky `previously known bad block` failures
- [ ] No regression on other `hive-eest` shards

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>