[BUG] Message queue race condition causes messages to vanish during LLM processing

[hannesrudolph]

Type

Bug

Problem / Value

Messages sent from the chat UI silently disappear when sent at a specific timing during message queue processing, causing user frustration and lost input. This affects all users when they send a message while a previously queued message is being processed by the LLM.

Context

Affects all users when sending messages through the chat UI while the message queue is being processed. The issue occurs when:

• A user sends message A, which gets queued
• Message A is dequeued and begins LLM processing
• User sends message B while message A is still being processed
• Message B vanishes without being added to the queue
• If user sends message B again, it successfully gets queued

Current observed behavior: Messages sent during the brief window after a queued message is dequeued but before LLM processing completes are lost without any error indication.

Reproduction

1. Send a message from chat UI (message A) while LLM is busy - it gets added to queue
2. Wait for message A to come off the queue and start LLM processing
3. While message A is being processed by LLM, send another message (message B) from chat UI
4. Expected result: Message B should be added to the message queue
5. Actual result: Message B silently disappears without being queued or processed
6. Send message B again while message A is still processing - now it gets queued successfully

Constraints/Preferences

The message queue logic should ensure all user messages are captured during any LLM processing state, including when processing messages that were previously dequeued. The race condition appears to be in the timing check around line 802 in Task.ts where isMessageQueued is evaluated before the message handling logic, causing a window where new messages aren't properly queued.

[hannesrudolph]

Summary

• Probable root cause is a race between a one-time queue check in Task.ask() and the UI’s send-path: if a user fires a message in the tiny window before the UI flips to “busy,” it’s sent as an askResponse (not queued) while no ask is actually waiting — so it “disappears.”
• Evidence:
  • One-shot queue check + block: Task.ask() computes isMessageQueued once, and if no items it immediately blocks on pWaitFor. New messages that arrive after this check aren’t consumed until later.
  • UI path that bypasses queue: ChatView.handleSendMessage() sends askResponse "messageResponse" for ongoing tasks when sendingDisabled is false. In the brief gap before isStreaming toggles, this can occur while no ask is pending.
  • askResponse always forwards to Task.handleWebviewAskResponse() via webviewMessageHandler(), but if there’s no pending ask (Task.taskAsk is undefined), nothing persists to the timeline — appearing as a silent drop.
  • Separately, queue draining is opportunistic (e.g., tools call Task.processQueuedMessages() once) and not actively monitored during waits.

Suggested fix (two-phase, minimal-risk)

1. Defensive routing in the extension for “free” user messages:

   • In webviewMessageHandler(), before calling handleWebviewAskResponse for askResponse === "messageResponse", check if provider.getCurrentTask()?.taskAsk exists.
   • If no ask is pending, route it to the queue instead: provider.getCurrentTask()?.messageQueueService.addMessage(text, images) and post state. This guarantees the message is captured even in the pre-busy window.

2. Actively observe the queue while waiting:

   • In Task.ask(), after computing isBlocking, attach a short-lived listener (or poll) on messageQueueService "stateChanged" to immediately consume newly queued messages while this ask is blocking (using the existing logic at Task.ask() to auto-approve tools vs. setMessageResponse for followups).

3. Drain after API turns:

   • After a request round completes in Task.recursivelyMakeClineRequests(), call Task.processQueuedMessages() in a loop (drain, not single pop) so any queued user messages are promptly submitted between LLM steps.

Optional UI hardening

• In ChatView.handleSendMessage(), when there’s no active ask (clineAskRef.current is undefined), prefer queuing whenever the model is in-flight (or just default to queuing during any transitioning state). This further narrows the window.

Impact

• All user messages are captured (either as ask responses when applicable or queued as new turns). This removes the “vanish” window and aligns with the early-check + continuous-monitoring approach noted in PR fix: resolve message queue race condition during LLM processing (#8536) #8538.

[roomote]

Hi @hannesrudolph,

I've implemented the fix for the message queue race condition as requested.

Summary of changes:
✅ Defensive routing in webviewMessageHandler to check for pending ask
✅ Active queue monitoring in Task.ask() with event listener
✅ Queue draining loop in recursivelyMakeClineRequests()
✅ UI hardening in ChatView to prefer queuing during transitions
✅ Comprehensive test coverage for race condition scenarios

All the suggested fixes have been implemented exactly as specified, plus the optional UI hardening for extra safety.

Pull Request: #8694

The implementation follows the multi-layered approach you outlined and ensures that all user messages are captured (either as ask responses when applicable or queued as new turns). This completely removes the "vanish" window.

Please review the PR and let me know if any adjustments are needed. Thanks for the detailed analysis and fix suggestions!