Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Human messages get starved in agent lane queues when agents communicate in loops [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70634•Fetched 2026-04-24 05:55:23
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
ewrurwteurwUewrurwteurwU
Participants
ewrurwteurwUewrurwteurwU
Timeline (top)
labeled ×1renamed ×1

ISSUE:

When multiple agents are actively communicating with each other, human-originated messages get indefinitely delayed in the agent's FIFO lane queue. Agent auto-reply loops can sustain themselves faster than the queue drains, effectively locking out the human operator even with no queueAhead.

Root Cause

ISSUE:

When multiple agents are actively communicating with each other, human-originated messages get indefinitely delayed in the agent's FIFO lane queue. Agent auto-reply loops can sustain themselves faster than the queue drains, effectively locking out the human operator even with no queueAhead.

Fix Action

Fix / Workaround

Agents stay unblocked, but human is blocked:

  • Human approval messages (e.g., "approved") sit unread while agents keep finishing secondary tasks and messaging each other mentioning they are waiting for approval
  • Critical corrections/direction changes can't reach agents in time
  • Only workaround is gateway restart, which is disruptive and drops in-flight work
  • This makes multi-agent setups with human-in-the-loop effectively unusable under load
RAW_BUFFERClick to expand / collapse

Summary

ISSUE:

When multiple agents are actively communicating with each other, human-originated messages get indefinitely delayed in the agent's FIFO lane queue. Agent auto-reply loops can sustain themselves faster than the queue drains, effectively locking out the human operator even with no queueAhead.

Problem to solve

REPRODUCTION:

  1. Two+ agents are in an active conversation (e.g., agent A sends to agent B, B auto-replies, A replies again)
  2. Human sends a message to agent B via webchat/channel
  3. Agent B's lane queue processes messages strictly FIFO
  4. Agent A's auto-generated replies arrive and are processed BEFORE the human's message
  5. Each processed reply generates another reply, keeping the agent-to-agent loop alive
  6. Human message keeps getting pushed back by the continuous stream and never reaches the front of the queue

Proposed solution

Add priority routing for human-originated messages in the command-queue:

  • When a message arrives from a human source (webchat, Discord, Signal, etc.), it should be inserted at the front of the target agent's lane queue (or at minimum, ahead of all agent-originated messages)
  • Alternatively: when a human message is queued, the agent pauses processing of agent messages until the human message is handled (one-shot priority)

This would require:

  1. A source or origin field on queue entries to distinguish human vs agent-originated messages
  2. Modified enqueue logic that places human messages at the head of the queue (or a priority sub-queue)
  3. The existing FIFO ordering preserved for agent-to-agent messages (no behavior change there)

This would not just solve the issue for situations where queueAhead=0, but also for situations with queueAhead=30

Alternatives considered

No response

Impact

Agents stay unblocked, but human is blocked:

  • Human approval messages (e.g., "approved") sit unread while agents keep finishing secondary tasks and messaging each other mentioning they are waiting for approval
  • Critical corrections/direction changes can't reach agents in time
  • Only workaround is gateway restart, which is disruptive and drops in-flight work
  • This makes multi-agent setups with human-in-the-loop effectively unusable under load

Evidence/examples

No response

Additional information

ENVIRONMENT:

  • OpenClaw 2026.4.20
  • Multi-agent setup (6 agents, Discord channels)
  • Fedora 43, Node v22.22.0

extent analysis

TL;DR

Implement priority routing for human-originated messages in the command-queue to prevent indefinite delays.

Guidance

  • Add a source or origin field to queue entries to distinguish human vs agent-originated messages.
  • Modify enqueue logic to place human messages at the head of the queue or in a priority sub-queue.
  • Preserve existing FIFO ordering for agent-to-agent messages to maintain current behavior.
  • Consider implementing a one-shot priority mechanism that pauses agent message processing until a human message is handled.

Example

// Example of modified enqueue logic
function enqueueMessage(message) {
  if (message.origin === 'human') {
    // Insert human message at the head of the queue
    queue.unshift(message);
  } else {
    // Preserve FIFO ordering for agent-to-agent messages
    queue.push(message);
  }
}

Notes

The proposed solution requires changes to the queue management system, which may have implications for the overall system architecture. Additionally, the one-shot priority mechanism may introduce additional complexity and potential edge cases.

Recommendation

Apply the proposed workaround by implementing priority routing for human-originated messages, as it directly addresses the issue and prevents indefinite delays.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#agent setup#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Human messages get starved in agent lane queues when agents communicate in loops [1 participants]