Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Feishu per-chat queue can hang indefinitely, leaving later P2P messages queued [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#70133•Fetched 2026-04-23 07:28:51
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
loyurloyur
Participants
loyurloyur

In the Feishu channel, a single p2p message can hang for minutes without dispatch complete, and later messages in the same chat remain queued behind it until the stuck task eventually finishes or the gateway is restarted.

Root Cause

In the Feishu channel, a single p2p message can hang for minutes without dispatch complete, and later messages in the same chat remain queued behind it until the stuck task eventually finishes or the gateway is restarted.

Fix Action

Fix / Workaround

Summary

In the Feishu channel, a single p2p message can hang for minutes without dispatch complete, and later messages in the same chat remain queued behind it until the stuck task eventually finishes or the gateway is restarted.

Steps to reproduce

  1. Start OpenClaw 2026.4.20 with Feishu enabled in websocket mode.
  2. Send a p2p message to the Feishu bot.
  3. Observe a log line like: feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:...)
  4. Before that message produces dispatch complete, send another p2p message in the same chat.
  5. Observe the later message is logged as: message ... in chat ... — queued
  6. Observe no reply for the later message until the earlier stuck task completes, or recover by restarting the gateway.

Actual behavior

Observed twice on the same system:

  • At 2026-04-22 18:47:51 +08:00, a p2p message started dispatching to agent:baiqi:feishu:direct:...
  • At 18:51:07 and 18:53:01, later messages in the same chat were logged as queued
  • dispatch complete for the original stuck task did not appear until 18:55:23
  • After gateway restart, the same pattern recurred:
    • 18:57:32 dispatch started
    • 18:59:46 a later message in the same chat was already queued
    • no dispatch complete had appeared for the earlier task by then

Code Example

2026-04-22T18:47:51.589+08:00 [feishu] feishu[default]: message om_x100b51be3bbe6c98b321ee723f2033a in chat oc_e0997af681c870903a32dadb36422fa0 — immediate
2026-04-22T18:47:51.597+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:ou_8968f16286b54723a71566fe6fc701a5)
2026-04-22T18:51:07.893+08:00 [feishu] feishu[default]: message om_x100b51becf7b90b4b368bed8b68ff02 in chat oc_e0997af681c870903a32dadb36422fa0 — queued
2026-04-22T18:53:01.431+08:00 [feishu] feishu[default]: message om_x100b51bec60368b8b2c4e01adba9bbb in chat oc_e0997af681c870903a32dadb36422fa0 — queued
2026-04-22T18:55:23.936+08:00 [feishu] feishu[default]: dispatch complete (queuedFinal=true, replies=1)

2026-04-22T18:57:31.924+08:00 [feishu] feishu[default]: message om_x100b51bed77564b4b3ce1f22ca0c845 in chat oc_e0997af681c870903a32dadb36422fa0 — immediate
2026-04-22T18:57:32.341+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:ou_8968f16286b54723a71566fe6fc701a5)
2026-04-22T18:59:46.402+08:00 [feishu] feishu[default]: message om_x100b51beeced0134b4b217eaf4ecc30 in chat oc_e0997af681c870903a32dadb36422fa0 — queued
RAW_BUFFERClick to expand / collapse

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

In the Feishu channel, a single p2p message can hang for minutes without dispatch complete, and later messages in the same chat remain queued behind it until the stuck task eventually finishes or the gateway is restarted.

Steps to reproduce

  1. Start OpenClaw 2026.4.20 with Feishu enabled in websocket mode.
  2. Send a p2p message to the Feishu bot.
  3. Observe a log line like: feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:...)
  4. Before that message produces dispatch complete, send another p2p message in the same chat.
  5. Observe the later message is logged as: message ... in chat ... — queued
  6. Observe no reply for the later message until the earlier stuck task completes, or recover by restarting the gateway.

Expected behavior

A stuck Feishu task should not block the same chat indefinitely. The queue should eventually release or time out so later messages can continue processing.

Actual behavior

Observed twice on the same system:

  • At 2026-04-22 18:47:51 +08:00, a p2p message started dispatching to agent:baiqi:feishu:direct:...
  • At 18:51:07 and 18:53:01, later messages in the same chat were logged as queued
  • dispatch complete for the original stuck task did not appear until 18:55:23
  • After gateway restart, the same pattern recurred:
    • 18:57:32 dispatch started
    • 18:59:46 a later message in the same chat was already queued
    • no dispatch complete had appeared for the earlier task by then

OpenClaw version

OpenClaw 2026.4.20 (115f05d)

Operating system

macOS 26.4.1 (Build 25E253)

Install method

NOT_ENOUGH_INFO

Model

google-gemini-cli / gemini-3-flash-preview

Provider / routing chain

openclaw -> google-gemini-cli

Additional provider/model setup details

Observed on the Feishu channel with:

  • connectionMode: websocket
  • streaming: true
  • replyMode: auto

The stuck session key in the observed runs was agent:baiqi:feishu:direct:....

Logs, screenshots, and evidence

2026-04-22T18:47:51.589+08:00 [feishu] feishu[default]: message om_x100b51be3bbe6c98b321ee723f2033a in chat oc_e0997af681c870903a32dadb36422fa0 — immediate
2026-04-22T18:47:51.597+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:ou_8968f16286b54723a71566fe6fc701a5)
2026-04-22T18:51:07.893+08:00 [feishu] feishu[default]: message om_x100b51becf7b90b4b368bed8b68ff02 in chat oc_e0997af681c870903a32dadb36422fa0 — queued
2026-04-22T18:53:01.431+08:00 [feishu] feishu[default]: message om_x100b51bec60368b8b2c4e01adba9bbb in chat oc_e0997af681c870903a32dadb36422fa0 — queued
2026-04-22T18:55:23.936+08:00 [feishu] feishu[default]: dispatch complete (queuedFinal=true, replies=1)

2026-04-22T18:57:31.924+08:00 [feishu] feishu[default]: message om_x100b51bed77564b4b3ce1f22ca0c845 in chat oc_e0997af681c870903a32dadb36422fa0 — immediate
2026-04-22T18:57:32.341+08:00 [feishu] feishu[default]: dispatching to agent (session=agent:baiqi:feishu:direct:ou_8968f16286b54723a71566fe6fc701a5)
2026-04-22T18:59:46.402+08:00 [feishu] feishu[default]: message om_x100b51beeced0134b4b217eaf4ecc30 in chat oc_e0997af681c870903a32dadb36422fa0 — queued

Local code inspection suggests the Feishu per-chat serial queue does not have a timeout/release guard:

  • extensions/openclaw-lark/src/channel/chat-queue.js
  • extensions/openclaw-lark/src/messaging/inbound/dispatch.js

Impact and severity

Affected: Feishu p2p chats on this installation Severity: High (blocks replies in the affected chat) Frequency: Observed 2 times in a row on 2026-04-22 Consequence: Later user messages in the same chat do not get processed until the stuck task finishes or the gateway is restarted

Additional information

This appears distinct from issue #58953. That issue reports replies=0 after gateway restart and recovery after a group-chat wake-up. This report is about one Feishu task occupying the per-chat queue for minutes, causing later messages in the same chat to remain queued.

extent analysis

TL;DR

Implement a timeout or release mechanism for the Feishu per-chat serial queue to prevent indefinite blocking of later messages.

Guidance

  • Review the extensions/openclaw-lark/src/channel/chat-queue.js and extensions/openclaw-lark/src/messaging/inbound/dispatch.js files to understand the current queue implementation.
  • Consider adding a timeout or release guard to the per-chat serial queue to allow later messages to be processed even if a task is stuck.
  • Investigate the cause of the stuck task and address the root issue to prevent it from happening in the first place.
  • Test the updated queue implementation to ensure it correctly handles stuck tasks and allows later messages to be processed.

Example

// Example of a simple timeout implementation
const queue = [];
const timeout = 30000; // 30 seconds

function processQueue() {
  const task = queue.shift();
  if (task) {
    // Process the task
    dispatchTask(task);
  } else {
    // If the queue is empty, check for stuck tasks
    const stuckTasks = queue.filter((task) => task.startTime + timeout < Date.now());
    stuckTasks.forEach((task) => {
      // Release the stuck task and allow later messages to be processed
      queue.splice(queue.indexOf(task), 1);
    });
  }
}

Notes

The provided code snippet is a simplified example and may not be directly applicable to the OpenClaw codebase. A thorough review of the existing code and testing of the updated implementation are necessary to ensure correct functionality.

Recommendation

Apply a workaround by implementing a timeout or release mechanism for the Feishu per-chat serial queue. This will allow later messages to be processed even if a task is stuck, preventing indefinite blocking of the chat.

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…

FAQ

Expected behavior

A stuck Feishu task should not block the same chat indefinitely. The queue should eventually release or time out so later messages can continue processing.

#installation#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING