Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Concurrent message handling per session (async agent turns) [1 pull requests, 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#56880•Fetched 2026-04-08 01:46:35
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
darealgegedarealgege
Participants
darealgegedarealgege
Timeline (top)
cross-referenced ×1

PR fix notes

PR #57239: feat: add fast-lane override for immediate response execution

Description (problem / solution / changelog)

Summary

  • add a fast-lane path for short inbound messages when a session already has an active run
  • bypass followup queueing for eligible quick messages and execute them immediately using an isolated transient run context
  • keep existing queue behavior as default and gate fast-lane behavior behind strict message heuristics
  • add queue-policy support for explicit "run now while active" override and unit coverage

Why

Long-running turns currently block quick follow-up messages in the same session, which creates high perceived latency in fast chat channels (especially Discord). This change preserves the existing safe queue model for normal traffic while allowing low-risk, short messages to get timely responses during busy turns.

What changed

  • src/auto-reply/reply/get-reply-run.ts
    • detect fast-lane candidates (short, single-line, non-command quick phrases)
    • when a run is active and message would be queued, create a transient fast-lane run context
    • append a fast-lane system instruction to keep replies concise and avoid unnecessary tools
    • force immediate execution instead of enqueue-followup for these candidate messages
  • src/auto-reply/reply/agent-runner.ts
    • thread a forceRunNowWhenActive flag into queue-action selection
  • src/auto-reply/reply/queue-policy.ts
    • honor forceRunNowWhenActive by returning run-now even while active
  • src/auto-reply/reply/queue-policy.test.ts
    • add test coverage for the fast-lane override path

Behavior notes

  • default queue behavior remains unchanged for non-fast-lane messages
  • fast-lane only applies when all conditions are met:
    • active run exists
    • current queue mode would follow up
    • active run is not currently streaming
    • message matches quick-message heuristics and is not a control command

Verification

  • pnpm tsgo ✅
  • lints on touched files via IDE diagnostics ✅
  • attempted targeted test:
    • pnpm test -- src/auto-reply/reply/queue-policy.test.ts
    • currently hangs in this local environment before case output (same in serial profile); process was stopped after no progress

Risk / follow-up

  • low-to-moderate: introduces a new execution path under active-session contention
  • follow-up recommended:
    • add integration tests around busy-session fast-lane behavior in get-reply-run / reply-flow
    • validate behavior in Discord channel smoke test (long turn + quick follow-up)

References

Closes #56880

Changed files

  • src/agents/pi-embedded-runner/run.ts (modified, +3/-1)
  • src/agents/pi-embedded-runner/run/params.ts (modified, +2/-0)
  • src/auto-reply/reply/agent-runner-utils.ts (modified, +1/-0)
  • src/auto-reply/reply/agent-runner.ts (modified, +3/-0)
  • src/auto-reply/reply/get-reply-run.ts (modified, +109/-28)
  • src/auto-reply/reply/queue-policy.test.ts (modified, +24/-0)
  • src/auto-reply/reply/queue-policy.ts (modified, +4/-0)
  • src/auto-reply/reply/queue/types.ts (modified, +3/-0)
RAW_BUFFERClick to expand / collapse

Problem

Currently, when an agent is processing a message on Discord, all subsequent messages from the same user/channel are queued and wait until the current turn completes before processing begins. This creates a significant UX bottleneck:

Scenario:

  1. User asks a complex question (e.g., debugging a config issue — many tool calls, 2+ minutes)
  2. While agent is working, user sends a quick follow-up ("what time is it?" / "yes" / "never mind")
  3. The quick message sits in queue until the long-running turn finishes
  4. User waits 2+ minutes for what should be a 1-second response

This is especially painful on Discord where conversations are naturally fast-paced and interleaved.

Current Behavior

  • Messages are processed sequentially per session (FIFO queue)
  • A long-running agent turn blocks all subsequent messages
  • Queued messages are batched and delivered after the current turn completes
  • The user sees "Bütyök is thinking..." with no way to get a quick response

Desired Behavior

Allow concurrent message handling within a session, so that:

  1. A new incoming message can spawn a parallel agent turn while another is still running
  2. Short/simple messages get fast responses even when a complex task is in progress
  3. The agent maintains context awareness across concurrent turns (knows what's in-flight)
  4. Optionally, the agent can decide to interrupt/deprioritize the current task if a new message is more urgent

Possible Implementation Ideas

  • Parallel turn slots per session (configurable maxConcurrentTurns: 2-3)
  • Priority-based routing: quick messages (short text, no tool calls expected) get a fast lane
  • Turn interruption: new messages can signal the agent to pause/checkpoint the current task
  • Independent sub-turns: each message gets its own turn context but shares session memory

Considerations

  • Context coherence: concurrent turns need to be aware of each other to avoid conflicts
  • Tool execution safety: two turns writing the same file simultaneously could cause issues
  • Rate limits: more concurrent turns = more API calls
  • Discord threading: could leverage Discord threads as a natural parallelism boundary

Use Cases

  1. User sends a complex task, then immediately asks a simple question → both get timely responses
  2. User sends "cancel" or "never mind" → agent can interrupt the current long-running task
  3. Multiple users in a group chat → messages from different users don't block each other

Environment

  • OpenClaw version: 2026.3.28
  • Channel: Discord (but applies to all chat channels)

extent analysis

Fix Plan

To implement concurrent message handling, we will introduce parallel turn slots per session. This will allow new incoming messages to spawn parallel agent turns while another is still running.

Step-by-Step Solution:

  1. Configure maxConcurrentTurns: Introduce a new configuration option maxConcurrentTurns to control the number of parallel turns allowed per session.
  2. Modify Message Queue: Update the message queue to support concurrent processing. This can be achieved by using a thread pool or an asynchronous queue.
  3. Implement Turn Context Management: Develop a mechanism to manage turn contexts across concurrent turns. This will ensure context coherence and avoid conflicts.

Example Code (Python):

import asyncio
from concurrent.futures import ThreadPoolExecutor

class Agent:
    def __init__(self, max_concurrent_turns):
        self.max_concurrent_turns = max_concurrent_turns
        self.executor = ThreadPoolExecutor(max_workers=max_concurrent_turns)

    async def process_message(self, message):
        # Process the message in a separate thread
        loop = asyncio.get_running_loop()
        return await loop.run_in_executor(self.executor, self._process_message, message)

    def _process_message(self, message):
        # Simulate message processing time
        import time
        time.sleep(2)  # Replace with actual processing logic
        return "Message processed"

# Usage
agent = Agent(max_concurrent_turns=3)
async def main():
    messages = ["Message 1", "Message 2", "Message 3"]
    tasks = [agent.process_message(message) for message in messages]
    results = await asyncio.gather(*tasks)
    print(results)

asyncio.run(main())

Verification

To verify the fix, test the agent with multiple concurrent messages and ensure that:

  • Short messages receive timely responses even when a complex task is in progress.
  • The agent maintains context awareness across concurrent turns.
  • The maxConcurrentTurns configuration option controls the number of parallel turns allowed.

Extra Tips

  • Monitor the agent's performance and adjust the maxConcurrentTurns value accordingly to avoid overwhelming the system.
  • Consider implementing priority-based routing to prioritize quick messages and ensure timely responses.
  • Leverage Discord threading as a natural parallelism boundary to improve performance and reduce conflicts.

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…
#api#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