fix(auto-reply): avoid silent completion when dispatch produces no sendable reply#63025
fix(auto-reply): avoid silent completion when dispatch produces no sendable reply#63025Leon-llb wants to merge 5 commits into
Conversation
在普通消息分发无可发送输出时补发错误提示 减少 replies=0 导致的用户侧静默无响应 保留显式静默分支与现有 hook 行为
Greptile SummaryThis PR adds a narrow fallback final reply in Confidence Score: 5/5Safe to merge — the fallback is narrowly scoped, mutually exclusive with existing silent branches, and covered by regression tests. All findings are P2. The logic is correct: the fallback condition guards properly with !shouldRouteToOriginating, blockCount === 0, counts.tool === 0, counts.block === 0, and counts.final === 0, making it mutually exclusive with the TTS block-streaming path and every intentional early-return. No P0/P1 issues found. No files require special attention.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const EMPTY_RUN_FALLBACK_TEXT = | ||
| "I couldn't produce a sendable reply for that request. A tool may have failed, timed out, or been blocked. Please retry with a narrower task or a different source."; |
There was a problem hiding this comment.
EMPTY_RUN_FALLBACK_TEXT says "A tool may have failed, timed out, or been blocked", but the fallback fires when counts.tool === 0 (no tool results were dispatched). In the zero-tool case the message slightly misattributes the empty output. Consider a more neutral phrasing like "I couldn't produce a reply for that request. Please try again or rephrase your message."
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/auto-reply/reply/dispatch-from-config.ts
Line: 85-86
Comment:
**Fallback message may mislead when no tools were invoked**
`EMPTY_RUN_FALLBACK_TEXT` says "A tool may have failed, timed out, or been blocked", but the fallback fires when `counts.tool === 0` (no tool results were dispatched). In the zero-tool case the message slightly misattributes the empty output. Consider a more neutral phrasing like "I couldn't produce a reply for that request. Please try again or rephrase your message."
How can I resolve this? If you propose a fix, please make it concise.避免在无工具输出场景中误导性归因 同步更新回归测试断言
合并 origin/main 并保留空回复兜底修复 同时保留主干新的媒体类型规范化实现
避免通用 fallback 误伤 Slack 无回复也合法的 ack 场景 仅在 direct/private 类会话且确实无可发送输出时补发提示 补充频道消息回归测试，保持现有静默分支行为不变
|
Addressed the CI regression by narrowing the fallback to direct/private chat contexts only. All checks are now passing. |
|
Thanks for the context here. I did a careful shell check against current Close this older PR as mostly implemented on main: the useful no-visible-reply fallback work is now covered by a safer policy-aware eligibility signal and Feishu delivery fallback shipped in v2026.6.6, while remaining cross-channel semantics are tracked by the canonical maintainer issue. So I’m closing this older PR as already covered on Review detailsBest possible solution: Keep the shipped v2026.6.6 policy-aware fallback eligibility and Feishu delivery path, and use #87561 for remaining cross-channel contract work. Do we have a high-confidence way to reproduce the issue? No high-confidence current-main failing reproduction remains for the central shipped Feishu no-visible path. Source and release inspection show current main/v2026.6.6 returns fallback eligibility and sends the sanitized Feishu fallback while preserving intentional silence and suppression policy. Is this the best way to solve the issue? No, this stale branch is no longer the best way to solve the issue. Current main uses a narrower channel-owned fallback path, and remaining cross-channel behavior belongs in the canonical durable delivery contract issue. Security review: Security review needs attention: The stale diff is security/policy-sensitive because it can send a fallback outside current source-reply suppression boundaries.
AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against e7ee1c55b433; fix evidence: release v2026.6.6, commit 7c15c2765ebb. |
|
Codex review: needs maintainer review before merge. What this changes: The PR adds a static error fallback in Maintainer follow-up before merge: This is an open implementation PR with a valid current-main gap, but the remaining action is maintainer review of delivery-policy and chat-type semantics rather than an automated replacement fix. Review detailsBest possible solution: Land a narrow dispatch-level empty-output fallback only after final queued counts are known, guarded by delivery policy, direct-style conversation policy, no routed-origin delivery, no queued final/tool/block output, no block-stream/TTS output, and no intentional handled/no-text branch. Use Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against acae48b790fa. |
clawsweeper
Bot
added
the
mantis: telegram-visible-proof
openclaw-barnacle
Bot
added
the
triage: needs-real-behavior-proof
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
ClawSweeper PR egg 🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat. Where did the egg go?
|
|
This pull request has been automatically marked as stale due to inactivity. |
clawsweeper
Bot
added
rating: 🌊 off-meta tidepool
clawsweeper
Bot
removed
the
mantis: telegram-visible-proof
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
ClawSweeper applied the proposed close for this PR.
|
1 participant
Summary
This fixes a silent completion path in
dispatchReplyFromConfig.In the current flow, a normal user message can make it through dispatch and still end with no sendable output, leaving the user with no reply and no visible error. In logs this shows up as
dispatch complete (queuedFinal=false, replies=0).What Changed
final,tool, orblockoutputScope
This PR fixes the "silent no-reply" behavior only.
It does not change search/tool execution behavior, and it does not solve cases where a long-running task times out after repeated upstream tool failures.
Testing
Ran:
./node_modules/.bin/vitest run --config vitest.config.ts src/auto-reply/reply/dispatch-from-config.test.ts -t "sends a fallback final reply when model dispatch produces no sendable output"./node_modules/.bin/vitest run --config vitest.config.ts src/auto-reply/reply/dispatch-from-config.test.ts -t "silently short-circuits when hook returns handled without text"Notes
AI-assisted: yes