openclaw - 💡(How to fix) Fix Feature Request: Pre-send queue check — suppress stale replies when newer messages are pending [3 comments, 4 participants]

reconlabs-kyle · 2026-03-17T07:21:02Z

[openclaw] Problem When a user sends a message and the agent is generating a response, the user may send a follow-up message that corrects, cancels, or superse… ## Problem When a user sends a message and the agent is generating a response, the user may send a follow-up message that corrects, cancels, or supersedes the original request. Currently, the agent completes its response to the **first** message and sends it, then processes the second message in a new turn. **Example:** ``` User: "Tell me the weather today" → Agent starts generating response (tool calls, LLM streaming) User: "Wait, I meant tomorrow's weather" → Message queued (collect mode) Agent: "Today's weather is sunny, 15°C..." ← stale, should not have been sent Agent: "Oh, you meant tomorrow? Tomorrow will be..." ← now processes correction ``` This creates an awkward UX where the agent responds to an already-superseded request, then immediately has to course-correct. The user sees two messages when they should see one. ## Proposed Solution: Pre-send Queue Check Before delivering the final reply to the channel (Telegram, Discord, etc.), check if there are **pending inbound messages in the queue** for the same session. ``` Agent turn completes → reply ready to send → Check: any pending messages in session queue? → YES: discard/defer reply, merge pending messages into next turn → NO: send reply normally ``` ### Behavior Details - **Check point**: After LLM generation completes, before `sendMessage` / channel delivery - **If pending messages exist**: - Skip sending the current reply (or mark it as superseded in session history) - Include the original response context + new messages in the next turn - The agent sees: "You were about to reply X, but the user sent a correction. Respond to the updated request." - **If no pending messages**: Send normally (zero latency impact) ### Why not existing modes? | Mode | Limitation | |------|-----------| | `collect` | Waits until turn ends, then delivers queued messages as followup. Does not prevent the stale reply from being sent. | | `interrupt` | Only aborts when `laneSize > 0` at enqueue time. Does not suppress the already-generated reply. In practice, short replies complete before the interrupt check runs. | | `steer` | Injects into current run at tool boundaries. Does not help when the LLM has already finished generating. | | `debounceMs` | Delays ALL responses (including single-message ones), degrading normal UX. | The gap is: **no mode prevents a completed-but-stale reply from being delivered when newer input is waiting.** ## Use Cases 1. **Correction**: User sends a question, immediately corrects it ("wait, I meant X") 2. **Cancellation**: User says "do X", then "actually, stop" — but the action is already queued to respond 3. **Multi-part input**: User sends context across 2-3 rapid messages; agent should wait for all of them before responding 4. **Conversational barge-in**: Similar to voice barge-in, but in text chat ## Additional Context - This is analogous to **text-based barge-in** — a concept well-established in voice AI (where user speech interrupts TTS playback) - The `collect` mode already coalesces queued messages, which is great — this proposal extends that by also suppressing the stale reply that triggered the queue - Zero performance impact on normal single-message flows (only adds a queue size check before send) ## Environment - OpenClaw latest (v2026.3.13+) - Channels: Telegram (primary), but applicable to all channels - Queue mode: collect (default)

Code Example

User: "Tell me the weather today"
  → Agent starts generating response (tool calls, LLM streaming)
User: "Wait, I meant tomorrow's weather"
  → Message queued (collect mode)
Agent: "Today's weather is sunny, 15°C..." ← stale, should not have been sent
Agent: "Oh, you meant tomorrow? Tomorrow will be..." ← now processes correction

---

Agent turn completes → reply ready to send
  → Check: any pending messages in session queue?
  → YES: discard/defer reply, merge pending messages into next turn
  → NO: send reply normally

Problem

When a user sends a message and the agent is generating a response, the user may send a follow-up message that corrects, cancels, or supersedes the original request. Currently, the agent completes its response to the first message and sends it, then processes the second message in a new turn.

Example:

User: "Tell me the weather today"
  → Agent starts generating response (tool calls, LLM streaming)
User: "Wait, I meant tomorrow's weather"
  → Message queued (collect mode)
Agent: "Today's weather is sunny, 15°C..." ← stale, should not have been sent
Agent: "Oh, you meant tomorrow? Tomorrow will be..." ← now processes correction

This creates an awkward UX where the agent responds to an already-superseded request, then immediately has to course-correct. The user sees two messages when they should see one.

Proposed Solution: Pre-send Queue Check

Before delivering the final reply to the channel (Telegram, Discord, etc.), check if there are pending inbound messages in the queue for the same session.

Agent turn completes → reply ready to send
  → Check: any pending messages in session queue?
  → YES: discard/defer reply, merge pending messages into next turn
  → NO: send reply normally

Behavior Details

Check point: After LLM generation completes, before sendMessage / channel delivery
If pending messages exist:
- Skip sending the current reply (or mark it as superseded in session history)
- Include the original response context + new messages in the next turn
- The agent sees: "You were about to reply X, but the user sent a correction. Respond to the updated request."
If no pending messages: Send normally (zero latency impact)

Why not existing modes?

Mode	Limitation
`collect`	Waits until turn ends, then delivers queued messages as followup. Does not prevent the stale reply from being sent.
`interrupt`	Only aborts when `laneSize > 0` at enqueue time. Does not suppress the already-generated reply. In practice, short replies complete before the interrupt check runs.
`steer`	Injects into current run at tool boundaries. Does not help when the LLM has already finished generating.
`debounceMs`	Delays ALL responses (including single-message ones), degrading normal UX.

The gap is: no mode prevents a completed-but-stale reply from being delivered when newer input is waiting.

Use Cases

Correction: User sends a question, immediately corrects it ("wait, I meant X")
Cancellation: User says "do X", then "actually, stop" — but the action is already queued to respond
Multi-part input: User sends context across 2-3 rapid messages; agent should wait for all of them before responding
Conversational barge-in: Similar to voice barge-in, but in text chat

Additional Context

This is analogous to text-based barge-in — a concept well-established in voice AI (where user speech interrupts TTS playback)
The collect mode already coalesces queued messages, which is great — this proposal extends that by also suppressing the stale reply that triggered the queue
Zero performance impact on normal single-message flows (only adds a queue size check before send)

Environment

OpenClaw latest (v2026.3.13+)
Channels: Telegram (primary), but applicable to all channels
Queue mode: collect (default)

extent analysis

Fix Plan

To implement the pre-send queue check, follow these steps:

Modify the sendMessage function to check for pending messages in the session queue before sending the reply.
If pending messages exist, discard the current reply and merge the pending messages into the next turn.
If no pending messages exist, send the reply normally.

Example code snippet:

def sendMessage(reply, session):
    # Check for pending messages in the session queue
    if session.hasPendingMessages():
        # Discard the current reply and merge pending messages into the next turn
        session.mergePendingMessages()
        return
    
    # Send the reply normally
    channel.send(reply)

class Session:
    def __init__(self):
        self.pendingMessages = []

    def hasPendingMessages(self):
        return len(self.pendingMessages) > 0

    def mergePendingMessages(self):
        # Merge the pending messages into the next turn
        # This can be implemented based on the specific requirements
        pass

Verification

To verify that the fix worked, test the following scenarios:

Send a message and then immediately send a correction message.
Send a message and then immediately send a cancellation message.
Send multiple messages in rapid succession and verify that the agent waits for all of them before responding.

Extra Tips

Make sure to handle edge cases, such as when the user sends multiple correction messages in a row.
Consider adding a timeout to the pre-send queue check to prevent the agent from waiting indefinitely for new messages.
Review the implementation to ensure that it does not introduce any performance issues or latency.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix Feature Request: Pre-send queue check — suppress stale replies when newer messages are pending [3 comments, 4 participants]

Recommended Tools

GitHub issue graph ai analysis

Code Example

Problem

Proposed Solution: Pre-send Queue Check

Behavior Details

Why not existing modes?

Use Cases

Additional Context

Environment

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix Feature Request: Pre-send queue check — suppress stale replies when newer messages are pending [3 comments, 4 participants]

Recommended Tools

GitHub issue graph ai analysis

Code Example

Problem

Proposed Solution: Pre-send Queue Check

Behavior Details

Why not existing modes?

Use Cases

Additional Context

Environment

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

RELATED_DISCOVERY

TRENDING