openclaw - 💡(How to fix) Fix Control UI: mc() history merge discards local messages when server returns empty [1 comments, 2 participants]

Summary

The mc() message-merge function in the Control UI frontend discards locally-streamed messages when the server's chat.history response returns an empty array. This causes the first assistant response in a new session (or after /new) to vanish immediately after streaming completes.

This is a separate bug from the chatLoading skeleton flash fixed in #71844 / 1cce439. That fix prevents the skeleton from replacing visible messages during reloads. This bug is about the merge logic itself silently dropping messages.

Related: #71371, #71844

Reproduction

• Environment: WSL2 (Linux 6.6.x-microsoft-standard-WSL2), gateway on loopback
• Steps:
  1. Start a new session (or /new)
  2. Send a message — watch the assistant response stream in
  3. Response finalizes — message disappears
  4. Browser refresh recovers it
• Key condition: The backend hasn't persisted the turn by the time chat.history fires, so the server returns []
• VS Code extension: Not affected — only the Control UI web frontend
• More likely on WSL2 due to added virtual-network latency widening the race window

Root cause

In the minified bundle (index-*.js), the mc() merge function reconciles server history (e) with local messages (t):

function mc(e, t) {
  if (e.length === 0 || t.length === 0) return e;
  // ... merge logic ...
}

The problem is the early return: if (e.length === 0 || t.length === 0) return e. When the server returns empty (e = []) but the client has locally-streamed messages (t = [greeting]), it returns [] — wiping out the local messages.

Race sequence

1. /new → session key changes → yc(e) starts (generation N)
2. Assistant greeting streams → finalizes → push handler adds it to chatMessages
3. Turn completion calls yc(e) again (generation N+1)
4. yc() N+1: chat.history returns [] (backend hasn't committed yet)
5. mc([], [greeting]) → e.length === 0 → returns [] → greeting wiped
6. User sees empty chat until browser refresh

Suggested fix

Split the early-return condition so that empty server history preserves local messages:

- if (e.length === 0 || t.length === 0) return e;
+ if (t.length === 0) return e;
+ if (e.length === 0) return t;

This way:

• Server empty + local messages → keep local messages (fixes the bug)
• Server has data + local empty → keep server data (unchanged behavior)
• Both empty → returns empty (unchanged)

We've applied this patch locally alongside the chatLoading fix from #71844 and confirmed it resolves the issue. The combination of both fixes eliminates all message-disappearance symptoms we've observed over months of debugging.

Environment