openclaw - ✅(Solved) Fix [Bug] Feishu dispatch completes with replies=0 after upgrading to 2026.5.4 — replies not sent without streaming card [1 pull requests, 1 comments, 2 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#78123Fetched 2026-05-06 06:16:42
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Timeline (top)
cross-referenced ×2commented ×1

Root Cause

The bug is in the OpenClaw core reply dispatch mechanism:

  1. When a message triggers a reply without a streaming card, the reply dispatcher's counts.final remains 0
  2. Messages with Started Streaming card → replies=1 ✅
  3. Messages without streaming card → replies=0 ❌

Evidence from gateway logs (macmini DM path):

# Working (with streaming)
Started Streaming: cardId=..., messageId=om_...
dispatch complete (queuedFinal=true, replies=2)
Closed streaming

# Broken (without streaming)
DM from ou_...: [message content]
dispatching to agent
dispatch complete (queuedFinal=false, replies=0)  ← no streaming card

Fix Action

Fix / Workaround

After upgrading to OpenClaw 2026.5.4, Feishu bot accounts intermittently fail to send replies. Messages are received and processed by agents, but dispatch complete (queuedFinal=false, replies=0) and no message is sent to Feishu.

  1. Send any message to a Feishu bot (DM or group)
  2. Observe the gateway log: feishu[account]: dispatch complete (queuedFinal=false, replies=0)
  3. No reply appears in Feishu

The bug is in the OpenClaw core reply dispatch mechanism:

PR fix notes

PR #78129: fix: preserve final replies without block streaming

Description (problem / solution / changelog)

Fixes #78123.

Summary

  • always preserve the final assistant text when block replies are disabled, even if preview/partial callbacks were active
  • keeps Feishu-style preview/card streaming from being treated as final delivery when no streaming lane/card was actually opened
  • adds a regression test covering preview callbacks with block replies disabled

Tests

  • PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-core.config.ts src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.keeps-final-answer-with-preview.test.ts src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.keeps-assistanttexts-final-answer-block-replies-are.test.ts
  • git diff --check
  • PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-changed.mjs

Changed files

  • src/agents/pi-embedded-subscribe.subscribe-embedded-pi-session.keeps-final-answer-with-preview.test.ts (added, +38/-0)
  • src/agents/pi-embedded-subscribe.ts (modified, +5/-2)

Code Example

# Working (with streaming)
Started Streaming: cardId=..., messageId=om_...
dispatch complete (queuedFinal=true, replies=2)
Closed streaming

# Broken (without streaming)
DM from ou_...: [message content]
dispatching to agent
dispatch complete (queuedFinal=false, replies=0)  ← no streaming card
RAW_BUFFERClick to expand / collapse

Bug Description

After upgrading to OpenClaw 2026.5.4, Feishu bot accounts intermittently fail to send replies. Messages are received and processed by agents, but dispatch complete (queuedFinal=false, replies=0) and no message is sent to Feishu.

This affects both group chats and DM (p2p) sessions — it is not limited to group chat, though it is more prevalent there.

Reproduction Steps

  1. Send any message to a Feishu bot (DM or group)
  2. Observe the gateway log: feishu[account]: dispatch complete (queuedFinal=false, replies=0)
  3. No reply appears in Feishu

Affected accounts: happylife, capital-market, history-research, lc, macmini (all DM and group paths)

Root Cause Analysis

The bug is in the OpenClaw core reply dispatch mechanism:

  1. When a message triggers a reply without a streaming card, the reply dispatcher's counts.final remains 0
  2. Messages with Started Streaming card → replies=1 ✅
  3. Messages without streaming card → replies=0 ❌

Evidence from gateway logs (macmini DM path):

# Working (with streaming)
Started Streaming: cardId=..., messageId=om_...
dispatch complete (queuedFinal=true, replies=2)
Closed streaming

# Broken (without streaming)
DM from ou_...: [message content]
dispatching to agent
dispatch complete (queuedFinal=false, replies=0)  ← no streaming card

Timeline

  • May 05 08:33 UTC+8: Gateway restart loaded openclaw 2026.5.4
  • May 05 17:07: Last capital-market success before failure
  • May 05 18:25: capital-market first replies=0
  • May 05 21:35: macmini first replies=0 in DM
  • May 06 06:43: Feishu plugin reverted to 2026.5.3 — issue persists
  • May 06: openclaw 2026.5.4 still running — issue persists

Version Info

  • openclaw: 2026.5.4 (installed May 05 via auto-update)
  • @openclaw/feishu: 2026.5.3 (reverted from 2026.5.4, did not fix)
  • macOS: Darwin 25.4.0 (arm64)
  • Node: v25.6.1

Related Issues

  • #32903 — "dispatch completes with replies=0 — user sees no response"
  • #38258 — "Feishu: messages not delivered when blockStreamingDefault=on (queuedFinal=false, replies=0)"
  • #38686 — "Feishu channel fails to send replies despite successful dispatch"
  • larksuite/openclaw-lark#385 — "queuedFinal=false, replies=0 for group chat replies" (exact same symptom)

Expected Behavior

Every message that triggers an agent response should result in replies>=1 in the gateway log and a reply sent to Feishu, regardless of whether a streaming card is used.

Possible Cause

The counts.final logic in the core dispatch module may be incorrectly gated on streaming card presence. When a reply is generated without a streaming card (i.e., a simple text reply), the reply dispatcher is not being properly settled/queued, resulting in queuedFinal=false and replies=0.

extent analysis

TL;DR

The issue can be fixed by modifying the core dispatch module to correctly handle replies without streaming cards, ensuring counts.final is updated accordingly.

Guidance

  • Review the OpenClaw core reply dispatch mechanism to identify why counts.final remains 0 when a reply is triggered without a streaming card.
  • Investigate the dispatch complete logic to determine why replies=0 is logged when no streaming card is present.
  • Consider updating the counts.final logic to account for replies without streaming cards, ensuring queuedFinal=true and replies>=1 are correctly set.
  • Verify the fix by testing replies with and without streaming cards, checking the gateway log for dispatch complete messages with replies>=1.

Example

No code snippet is provided as the issue requires a deeper understanding of the OpenClaw core dispatch mechanism and its internal logic.

Notes

The issue persists even after reverting the Feishu plugin to version 2026.5.3, suggesting the problem lies within the OpenClaw core. The fact that replies=0 is logged when no streaming card is present indicates a potential issue with the counts.final logic.

Recommendation

Apply a workaround by modifying the core dispatch module to correctly handle replies without streaming cards, as the root cause is likely related to the counts.final logic. This will ensure that queuedFinal=true and replies>=1 are correctly set, allowing replies to be sent to Feishu.

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…

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 - ✅(Solved) Fix [Bug] Feishu dispatch completes with replies=0 after upgrading to 2026.5.4 — replies not sent without streaming card [1 pull requests, 1 comments, 2 participants]