openclaw - 💡(How to fix) Fix [Bug]: WebChat run-complete indicator fires before reply text renders (inverse of #84754)

Description

In WebChat on v2026.5.20, the run-complete indicator (progress bar → done) fires before the final reply chunks render in the UI. The progress bar transitions to its completion state, and then 2–5 seconds later the assistant's message text appears.

The reply does eventually arrive on its own (no refresh required) — but the UX is broken because the "done" indicator lies about delivery state.

This is the inverse-direction symptom of #84754 / PR #84565 (where the typing indicator persists after the response completes). Both bugs point to a race between the run-complete event and the final content-chunk flush.

Environment

• OpenClaw version: 2026.5.20 (e510042)
• Channel: WebChat (Control UI)
• Model: claude-cli/claude-opus-4-7 (oauth: anthropic:claude-cli)
• OS: Windows 10 Home (gateway host)
• Proxy: none (direct loopback)

Steps to Reproduce

1. Open WebChat at the gateway port.
2. Send a message that produces a moderate-length reply (a few paragraphs).
3. Watch the bottom-of-chat progress bar.
4. Observe: progress bar flips to its done / success state.
5. Observe: reply text does not yet appear in the conversation.
6. Wait 2–5 seconds — the reply text then renders into the conversation.

Expected Behavior

The run-complete indicator should fire only after the final assistant-message chunks have been rendered into the conversation view, so that "done" coincides with the user actually seeing the reply.

Actual Behavior

run-complete event arrives at the UI ahead of the final text chunks. The completion indicator races ahead of the rendered content, leaving the user staring at a "done" bar with no visible reply for a few seconds.

Notes

• Prior to the 2026.5.20 heartbeat-deferral fix (#82722 / CHANGELOG line 503), the more severe form of this bug required clicking "Refresh Chat Data" to see the reply at all. Since updating to 2026.5.20, refresh is no longer needed — content arrives on its own — but the event-ordering issue remains visible as the 2–5s delay described above.
• Related: #84754 (closed) and PR #84565 (proposes reconcileChatRunFromSessionsState after websocket session patches in ui/src/ui/controllers/sessions.ts). That fix targets the opposite direction (indicator stuck on) but touches the same reconciliation path — worth checking whether the same surface can be hardened to also delay run-complete until the final stream chunks have flushed.
• Suspected area: race between sessions.changed patch handling and final SSE/stream chunk delivery in the WebChat client controller.