Summary

ExecModule.UpdateForkChoice spawns the forkchoice work in a goroutine and waited on a done channel that closes only after that goroutine fully returns — i.e. after flush + commit + prune. For a merge-extending fork at tip the forkchoice result is already sent on outcomeCh before the commit (ParallelStateFlushing is on by default), so the <-done wait threw that early-send away and blocked the consensus client for the entire EL commit.

This removes the <-done wait: UpdateForkChoice returns as soon as the result lands on outcomeCh.

Live-tip A/B (this branch vs main)

Probe at the ExecutionClientDirect.ForkChoiceUpdate boundary (what Caplin's clstages loop blocks on), live mainnet tip, same datadir/machine/instrumentation:

~217× lower p50; distributions don't overlap (branch max 4.3 ms ≪ main min 96.7 ms). This matches release/3.4's ~1.4 ms at the same boundary. The Timings: Forkchoice commit=…ms line is unchanged — the commit still costs the same, it just no longer blocks the consensus loop. safe/finalized cadence is identical between branch and main, and wall does not correlate with safe/finalized changes, so this is not about forkchoice args.

Both A/B binaries are post-#21327, so the comparison isolates only the <-done change — the gap is not confounded by the #21008/#20035 regression (both sides already have its fix).

Scope / relationship to #21008

This is an independent FCU-response-latency improvement, not the fix for the #21008 in-sync regression. The bisection attributes #21008 to #20035, which is entirely CL-side (cl/phase1/forkchoice/*) and touches no execution/execmodule/ code — its getFilterBlockTree spec-deviation regressed GetHead at epoch boundaries and is itself already fixed on main by #21310/#21327. The <-done wait predates the bisection's good commit 19f44b15cd (it was added in #19981, and that commit measured 100% in-sync), so the EL-side blocking this PR removes is not what caused the 100→3% collapse. It is a real, separate cost worth removing on its own merits: at tip it returns the consensus loop to ~1 ms instead of ~260 ms (and avoids multi-second blocks when the commit overlaps a background merge/prune burst).

Why it's safe

The <-done was added (#19981) so a follow-up AssembleBlock could safely acquire the EL semaphore. That guarantee is preserved without it:

• In updateForkChoice, the defer e.semaphore.Release(1) is registered first, so it runs last — after every cleanup defer (ResetPendingUpdates, ClearWithUnwind, overlay Close). Any op that subsequently acquires the semaphore necessarily observes fully-settled state.
• ExecutionClientDirect.ForkChoiceUpdate already retries AssembleBlock (30× 200 ms) on semaphore contention, so a proposer FCU racing an in-flight commit resolves itself.
• release/3.4 has no <-done and is the proven-good baseline.
• Non-merge FCUs send their result at the end of updateForkChoice anyway, so their timing is unchanged.

Test plan

• execution/engineapi TestEngineApi* block-production suite (the FCU→AssembleBlock path <-done guarded)
• execution/execmodule/...
• cl/beacon/handler TestCaplinBlockProduction*
• make lint clean
• Live-tip A/B (this branch vs main): FCU-response wall p50 260 ms → 1.2 ms, 0 gap errors over an epoch

🤖 Generated with Claude Code