Bug Description

When a user sends a message via Feishu (and likely other channels), the dispatch pipeline can complete with queuedFinal=false and counts.final=0, meaning the agent processed the message but produced zero replies. The user receives no response whatsoever and perceives the bot as "stuck" (卡死).

Evidence from gateway.log

2025-07-18T09:54:07 feishu[feishu_doc]: dispatch complete (queuedFinal=false, replies=0)
2025-07-18T09:55:06 feishu[feishu_doc]: dispatch complete (queuedFinal=false, replies=0)

17 instances of replies=0 observed across 3 days in a single gateway.log.

Root Cause Analysis

dispatchReplyFromConfig() in src/auto-reply/reply/dispatch-from-config.ts returns { queuedFinal: false, counts: { final: 0 } } from multiple paths:

1. Line 164 — shouldSkipDuplicateInbound() → intentional skip (not a bug)
2. Line 323 — sendPolicy === "deny" → ACP blocks (not a bug)
3. Main agent path (line ~540) — Agent runs but replyResult is empty/null and blockCount === 0 → silent completion, no user feedback (THIS is the bug)

Path 3 happens when the agent's tool calls all fail (e.g., web_fetch returns 403) or the model returns no content. The dispatch layer faithfully reports 0 replies, but no fallback message is sent to the user.

At the channel level (extensions/feishu/src/bot.ts line 1523), the result is logged but no action is taken:

log(\`dispatch complete (queuedFinal=\${queuedFinal}, replies=\${counts.final})\`);

Suggested Fix

Option A (dispatch layer): When !queuedFinal && replies.length === 0 && blockCount === 0 after the main agent path, send a fallback reply (e.g., "I wasn't able to complete your request — please try again.").

Option B (return metadata): Add a reason field to the dispatch result ("duplicate_skip" / "send_policy_deny" / "completed") so callers can distinguish intentional skips from silent failures and apply channel-specific fallbacks.

Environment

• OpenClaw v2026.3.2
• macOS, launchd-managed gateway
• Feishu WebSocket channel
• Agent model: qwen3-max

Related

• [Feature]: Memory flush on /new and /reset (pre-reset memory save) #8185 (memory flush on /new — complementary)
• PR fix: exit(0) when port owned by another OpenClaw instance #32897 (gateway restart loop — discovered alongside this issue)