Fix message flash/disappear on send

[EricBlanquer]

Description

Fixes a race condition where user messages would briefly disappear then reappear when sending new messages.

Root Cause

The issue was caused by two independent code paths that could overwrite optimistic UI updates:

1. App.jsx (line 189): The file watcher checked activeSessions.has(selectedSession.id) but didn't account for temporary new-session-* IDs. This caused externalMessageUpdate to be incremented prematurely, triggering a message reload.

2. ChatInterface.jsx (line 3139): The useEffect syncing chatMessages with convertedMessages ran even during isLoading, overwriting optimistic UI updates before the server responded.

Changes

App.jsx

• Added check for temporary session IDs in active session detection
• Prevents race condition where activeSessions hasn't been updated yet with the real session ID

ChatInterface.jsx

• Added !isLoading condition to the chatMessages sync useEffect
• Preserves optimistic UI updates during active message sending

Testing

✅ Tested: Messages now stay visible during the entire send/response cycle without flashing

Why Both Fixes Are Needed

• The App.jsx fix prevents externalMessageUpdate from triggering the useEffect at line 3102, which calls setChatMessages(converted) directly (bypassing isLoading protection)
• The ChatInterface.jsx fix protects the useEffect at line 3138 that syncs via convertedMessages

Without both fixes, messages can still flash via the unprotected code path.

Summary by CodeRabbit

• Bug Fixes
  • Treats newly created/in-flight sessions as active to avoid race-condition updates that could trigger unnecessary reloads.
  • Prevents converted messages from overwriting the optimistic chat UI while data is loading, preserving in-progress message state.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Treats temporary session IDs prefixed with new-session- as active for WebSocket-driven updates to avoid missed updates, and adds an isLoading guard to the effect that copies convertedMessages into chatMessages so optimistic UI isn't overwritten during loads. (≈33 words)

Changes

Cohort / File(s)	Summary
WebSocket Session Activity Check src/App.jsx	Active-session check now considers exact session IDs or any temporary IDs starting with new-session- when deciding if WebSocket updates apply to the current view.
Optimistic UI Update Guard src/components/ChatInterface.jsx	Effect that syncs convertedMessages → chatMessages is guarded by isLoading and now includes isLoading in its dependency array to avoid overwriting optimistic updates.

Sequence Diagram(s)

(omitted)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Fix/session streamed to another chat #318: Similar session-activation and streaming-update guards affecting App.jsx and ChatInterface.jsx behavior.
• fix: navigate to the correct session ID when updating session state #275: Related to session-transition handling and temporary-session replacement/navigation logic.
• Feature/edit diff #216: Refactors session lifecycle helpers (e.g., replaceTemporarySession) that interact with temporary new-session-* IDs.

Suggested reviewers

• viper151

Poem

🐰
I hop on keys and patch the stream,
I stitch the new-session into the team,
I guard the chat when loaders play,
No lost lines on my watch today,
Nibble, hop — hooray! 🥕

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix message flash/disappear on send' directly summarizes the primary issue being addressed—preventing messages from briefly disappearing when sent—which aligns with the main changeset focused on fixing a race condition in message handling.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[blackmammoth]

@EricBlanquer can you also send detailed reproduction steps for this (including which LLM you picked for testing)?

[EricBlanquer]

@blackmammoth

Reproduction steps

Before the fix (message flash/disappear bug)

1. Start the app and select any project
2. Open a new session or existing session
3. Type a message and send it
4. Bug: The message briefly appears, then disappears for ~500ms, then reappears when the server confirms it

This happens because:

• The message is added optimistically to the UI
• A session-change event triggers a reload of messages from the server
• The server hasn't saved the message yet → the reload overwrites the optimistic message
• When the server finally saves, another update restores the message

After the fix

1. Same steps as above
2. Expected: Message appears immediately and stays visible without flashing

LLM used for testing

Tested with Claude Sonnet 4 (claude-sonnet-4-20250514) via Claude CLI.

The bug is not LLM-specific - it's a race condition in the frontend between optimistic UI updates and session reload events.

send 1, then send 2 : message 2 has disappeared

then reappeared

[blackmammoth]

@EricBlanquer I tried your reproduction and this is what I see on this branch:

There seems to be a lag to see the message after sending a new one.

Screen.Recording.2026-01-27.173947.mp4