openclaw - 💡(How to fix) Fix Control UI: chatLoading skeleton flash on history reload (WSL2 / high-latency localhost) [1 comments, 2 participants]

Summary

The chatLoading = true skeleton flash during yc() history reloads causes messages to visibly disappear on turn completion. This was partially addressed in v2026.4.24 (via pendingSessionMessageReloadSessionKey deferral), but the core issue remains: yc() unconditionally sets chatLoading = true, which swaps visible messages for a skeleton placeholder during the async chat.history round-trip.

On native localhost with small sessions, the gap is sub-frame. On WSL2 or any setup with higher localhost latency and larger sessions, it's clearly visible — messages vanish for a beat, then reappear.

Related: #71371 (closed by v2026.4.24, but this is the remaining half of the bug).

Reproduction

• Environment: WSL2 (Linux 6.6.x-microsoft-standard-WSL2), gateway on loopback (127.0.0.1)
• Sessions: 20-30+ child sessions, 200k+ tokens
• Steps: Send any message via Control UI, watch the chat area when the response finalizes
• Result: Messages flash-disappear (replaced by skeleton), then reappear when chat.history returns
• VS Code extension: Not affected — only the Control UI web frontend
• Browser refresh always recovers the messages

Root cause

In the history reload function (yc in the minified bundle):

e.chatLoading = !0, e.lastError = null;
try {
  let a;
  for (;;) try {
    a = await e.client.request('chat.history', { sessionKey: t, limit: 200 });
    break;
  } catch (i) { /* retry logic */ }
  // ... merge messages via mc() ...
  e.chatStream = null;
} finally {
  e.chatLoading = !1;
}

The chat renderer (qM) checks e.loading and replaces the message list with a skeleton:

${e.loading ? s`<div class="chat-loading-skeleton">...` : /* render actual messages */}

So when yc() fires after turn completion, messages are swapped for skeleton during the async wait. On high-latency localhost (WSL2 virtual network), this is perceptible.

Suggested fix

Only show the loading skeleton when there are no messages to display (initial load). When messages already exist, let the history reload happen silently:

- e.chatLoading = !0, e.lastError = null;
+ e.chatMessages.length === 0 && (e.chatLoading = !0), e.lastError = null;

This preserves the skeleton UX on first load while preventing the flash on subsequent reloads. The mc() merge function already handles reconciling server history with local state correctly, so the visual result is identical — just without the flash.

We've applied this patch locally and confirmed it resolves the issue completely.

Environment