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.
|
| 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. |
|
Codex review: needs real behavior proof before merge. Reviewed June 6, 2026, 12:47 AM ET / 04:47 UTC. Summary PR surface: Source +27, Tests +35. Total +62 across 2 files. Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Review detailsBest possible solution: Retry the Codex review after fixing the execution failure. Do we have a high-confidence way to reproduce the issue? Unclear. The review failed before ClawSweeper could establish a reproduction path. Is this the best way to solve the issue? Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction. AGENTS.md: unclear because the file could not be read completely. Codex review notes: model gpt-5.5, reasoning high; reviewed against 9313471fa579. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +27, Tests +35. Total +62 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
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 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. |
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