openclaw - 💡(How to fix) Fix [ACP] Events and errors emitted after turn-timeout are silently dropped in consumeAcpTurnStream [1 pull requests]

Summary

consumeAcpTurnStream drains the ACP runtime event stream after a turn-timeout but discards every event that arrives after the gate closes — including errors.

Source trace

src/acp/control-plane/manager.turn-stream.ts:28 drives a for await loop over runtime.runTurn(). An eventGate object controls delivery:

// :29-31
if (!params.eventGate.open) {
  continue;
}
// onOutputEvent, onEvent below — not reached after gate closes
await params.onEvent?.(event); // :43

The turn-timeout path at manager.core.ts:837 sets eventGate.open = false mid-stream. After this fires, the loop keeps draining the runtime iterator — gated events hit continue before delivery.

Captured errors are also swallowed. When the runtime emits an error event inside the loop (:34-38), streamError is set — but the surface-or-return check at :46 only throws when the gate is still open:

// :46
if (params.eventGate.open && streamError) {
  throw streamError;
}

An error event arriving after gate-close is captured and then silently discarded. The function returns normally with no indication that an error occurred.

Effect

Events and errors emitted by the runtime after the turn-timeout fires are lost. For responses that cross the timeout boundary by a small margin, callers lose information that would otherwise inform recovery decisions.

Design question — two fix shapes

I can open a PR for the preferred shape:

1. Deliver-then-cancel: keep calling params.onEvent after gate closes; skip only params.onOutputEvent. Late events stay observable. Error visibility is restored. Minimal change to the existing contract.

2. Synthesize-cancel-event: when gate closes, inject a synthetic { type: "cancelled", reason: "turn-timeout" } event and break the loop. Explicit cancellation signal for callers; cleaner protocol boundary.