openclaw - 💡(How to fix) Fix Bug: Loading animation persists after response completes (v2026.5.18) [1 comments, 2 participants]

Bug Report: Loading animation persists after response completes

Version: v2026.5.18 (Gateway)

Severity: Low

Description: When the assistant finishes typing a response, the three-dot loading animation in the chat interface continues to pulse indefinitely. The response itself is complete and delivered normally, but the loading indicator fails to clear.

Steps to reproduce:

1. Send a message to the assistant
2. Wait for the assistant to finish typing and deliver the response
3. Observe that the three-dot animation continues to pulse instead of stopping

Expected behavior: The loading animation should disappear immediately after the response is fully delivered.

Actual behavior: The loading animation remains visible and animating after the response is complete.

Workaround: Refreshing the page (Cmd+Shift+R) clears the stuck animation and restores normal behavior.

Additional notes:

• This appears to be a UI state management issue rather than a backend problem
• The assistant is functioning normally; only the visual indicator is affected
• Issue has been reproduced consistently but not on every single message

Additional details for developers:

• Channel: WebChat (webchat interface)
• Browser/OS: macOS 26.3 (arm64) / Safari or Chromium-based browser
• Gateway mode: local (ws://127.0.0.1:18789)
• Frontend connection: WebSocket-based real-time connection

Likely root cause: The WebSocket message carrying the "response complete" signal may arrive but the frontend animation state machine fails to transition from "loading" to "idle." This could be:

• A race condition where the animation is triggered mid-response and the clearing signal arrives before the component re-renders
• An edge case in the WebSocket message handling where the "end of turn" event is not properly consumed by the UI layer
• Missing error handling when the WebSocket frame arrives while the UI is in a specific state (e.g., during a re-render triggered by the response)

Could be related to:

• Streaming responses vs. non-streaming responses (animation may behave differently depending on whether the response is streamed or delivered in one chunk)
• Long responses vs. short responses (longer responses may have more opportunities for the animation state to get out of sync)
• Specific HTML/CSS implementation of the three-dot animation (whether it is a CSS animation, SVG, or canvas-based)

Debug suggestions:

• Add state logging on the frontend: log every WebSocket message type received and the current animation state
• Check if the animation state is properly reset on WebSocket "end" or "done" messages
• Compare behavior between streaming and non-streaming responses
• Check browser console for any silently caught errors during the response rendering phase