Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

A completed chat run can leave the Control UI/TUI stuck in a running or streaming state because the lifecycle terminal handler may return early after streamed assistant deltas were already delivered, suppressing the final chat event.

Steps to reproduce

1. Start a long-running chat run through the OpenClaw gateway with live chat streaming enabled.
2. Let assistant deltas stream successfully to the client so the response text is visible.
3. Hit a lifecycle terminal event (phase: "end" or phase: "error") where chatRunState.registry.peek(evt.runId) previously found a link, but chatRunState.registry.shift(evt.runId) returns undefined.
4. Observe that emitChatFinal(...) is skipped and the client can remain in streaming / running / Stop state even though the assistant text arrived.

Expected behavior

A terminal lifecycle event should always retire the visible chat run when enough session/run context exists to do so. If the registry entry drifted between peek() and shift(), the gateway should use the already-resolved sessionKey / eventRunId fallback and still emit the final chat event.

Actual behavior

The current terminal lifecycle path can return early before emitting chat final:

const chatLink = chatRunState.registry.peek(evt.runId);
// ... sessionKey/clientRunId/eventRunId resolved from chatLink or fallbacks ...

if (chatLink) {
  const finished = chatRunState.registry.shift(evt.runId);
  if (!finished) {
    clearAgentRunContext(evt.runId);
    return;
  }
  emitChatFinal(finished.sessionKey, finished.clientRunId, ...);
} else {
  emitChatFinal(sessionKey, eventRunId, ...);
}

If peek() succeeds but shift() misses, the code clears context and returns instead of using the same fallback path used when chatLink is absent.

OpenClaw version

Observed against 2026.4.26-era gateway behavior; current upstream main still contains the same code shape in src/gateway/server-chat.ts.

Operating system

Ubuntu 24.04 / Linux 6.17.0-22-generic x86_64

Install method

npm global

Model

venice/openai-gpt-54 in the observed local incident. The bug is in gateway lifecycle finalization and is not model-specific.

Provider / routing chain

OpenClaw gateway -> Venice/OpenAI-compatible provider in the observed local incident.

Additional provider/model setup details

The provider had already streamed assistant text successfully. The failure mode is downstream of provider generation: gateway lifecycle finalization skips emitChatFinal(...) after the streamed text is visible.

Logs, screenshots, and evidence

Observed symptoms:
- Full assistant reply text was visible from streamed deltas.
- Session transcript recorded completed assistant messages with stopReason: "stop".
- Session store later reported status: "done".
- Follow-up turns continued working on the same session.
- The UI/TUI activity state sometimes remained `streaming | connected` / running instead of retiring to idle.

Upstream code path observed in src/gateway/server-chat.ts on main:

const chatLink = chatRunState.registry.peek(evt.runId);
const eventSessionKey =
  typeof evt.sessionKey === "string" && evt.sessionKey.trim() ? evt.sessionKey : undefined;
const sessionKey =
  chatLink?.sessionKey ?? eventSessionKey ?? resolveSessionKeyForRun(evt.runId);
const clientRunId = chatLink?.clientRunId ?? evt.runId;
const eventRunId = chatLink?.clientRunId ?? evt.runId;

if (isControlUiVisible && sessionKey) {
  if (!isAborted) {
    if (chatLink) {
      const finished = chatRunState.registry.shift(evt.runId);
      if (!finished) {
        clearAgentRunContext(evt.runId);
        return;
      }
      emitChatFinal(finished.sessionKey, finished.clientRunId, ...);
    } else {
      emitChatFinal(sessionKey, eventRunId, ...);
    }
  }
}

Impact and severity

Affected: users of live gateway chat surfaces (Control UI/TUI/websocket clients) when the run registry entry drifts before terminal lifecycle handling. Severity: Medium to high. The generated answer may be visible, but the client can remain stuck in a running/streaming state and operators may think the run is still active. Frequency: Intermittent; depends on registry/lifecycle timing. Consequence: stuck Stop / streaming UI state, confusing operator feedback, possible need to restart or manually clear state.

Additional information

Suggested low-risk fix:

When chatLink exists but registry.shift(evt.runId) returns undefined, do not return before finalizing. Fall back to the already-resolved sessionKey and eventRunId and emit the final event once:

if (chatLink) {
  const finished = chatRunState.registry.shift(evt.runId);
  if (finished) {
    emitChatFinal(finished.sessionKey, finished.clientRunId, ...);
  } else {
    emitChatFinal(sessionKey, eventRunId, ...);
  }
} else {
  emitChatFinal(sessionKey, eventRunId, ...);
}

A local dist patch using this approach stopped the stuck-streaming symptom without changing transcript content or producing duplicate final assistant messages in the observed case.

Related-but-not-identical issue found before filing:

• #42011 describes Control UI stuck on Stop after embedded timeout / missing terminal lifecycle. This report is narrower: it identifies a specific terminal lifecycle finalization path where peek() can succeed, shift() can miss, and emitChatFinal(...) is suppressed.