[Bug]: Discord message_tool_only turns can append stale tool-failed warning after successful message send by xydttsw · Pull Request #93925 · openclaw/openclaw

xydttsw · 2026-06-17T04:19:51Z

AI-assisted PR. Implemented and verified with Claude (Claude Code).

Summary

What: Discord messages sent via message(action=send) can still have stale tool-failed warnings appended after a successful message send.
Root cause: deliveredSourceReplyViaMessageTool flags when a reply has been delivered via the message tool, but this flag was not considered in the hasUserFacingAssistantReply initialization. resolveToolErrorWarningPolicy then incorrectly concluded the turn had no user-visible reply and appended a stale warning.
Fix: Add deliveredSourceReplyViaMessageTool to the hasUserFacingAssistantReply initialization so that replies delivered via message tool are properly recognized as user-facing.

Real behavior proof

Behavior or issue addressed: Discord message_tool_only turns no longer append a stale tool-failed warning after a successful message send via message(action=send). The one-line fix ensures deliveredSourceReplyViaMessageTool is recognized in hasUserFacingAssistantReply so the warning policy does not incorrectly flag successful deliveries.

Real environment tested: TypeScript compilation + embedded agent runner unit test suite on openclaw main branch with Node.js v24.13.1 on Linux x64.

Exact steps or command run after this patch:
Applied the one-line change to src/agents/embedded-agent-runner/run/payloads.ts, then ran:

node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-embedded-agent.config.ts --reporter=verbose

Evidence after fix:
The change compiles cleanly and the full embedded agent runner test suite confirms no regressions:

-  let hasUserFacingAssistantReply = hasSourceReplyPayload;
+  let hasUserFacingAssistantReply = hasSourceReplyPayload || deliveredSourceReplyViaMessageTool;

The deliveredSourceReplyViaMessageTool flag is already set by the code path that handles message(action=send) deliveries and is used elsewhere to suppress redundant assistant artifacts. Adding it to hasUserFacingAssistantReply is the logical extension — when a reply was delivered via message tool, the user has seen it, so no warning should be appended.

Console output from the test run confirms 83/84 test files and 1478 tests pass as expected:

Test Files  83 passed | 1 failed (84)
     Tests  1478 passed | 58 skipped (1536)
  Duration  315.63s

The single failed suite (attempt.spawn-workspace.context-engine.test.ts) is a pre-existing hook timeout in an unrelated context-engine test — it also fails on the unmodified main branch and is unrelated to this payload change.

Observed result after fix:

TypeScript compilation: no type errors
All payload-related tests pass (no regressions)
hasUserFacingAssistantReply now correctly accounts for message-tool deliveries
The fix is a single boolean OR — minimal, safe, and consistent with how deliveredSourceReplyViaMessageTool is already used in the same module

What was not tested:

Full end-to-end test with a running Discord bot and real chat channels was not performed due to environment constraints. The fix relies on the existing embedded agent runner test coverage for payload building and warning resolution logic.

…ed warning after successful message send When Discord source-channel replies are delivered via message(action=send) (message_tool_only path), the final response is sent successfully but a stale tool-failed warning could still appear after it. This happens because deliveredSourceReplyViaMessageTool was not included in the hasUserFacingAssistantReply gate, so resolveToolErrorWarningPolicy treated the turn as having no user-facing reply and emitted a warning. Fix: include deliveredSourceReplyViaMessageTool in hasUserFacingAssistantReply initialization, so a successfully delivered message-tool reply counts as a user-facing assistant reply. Fixes openclaw#93875 Co-Authored-By: Claude <[email protected]>

github-actions · 2026-06-17T08:37:26Z

Dependency graph guard cleared

This PR no longer has blocked dependency graph changes. A future dependency graph change requires a fresh /allow-dependencies-change comment after the guard blocks that new head SHA.

Current SHA: 1081f63ecb279a920f375a50232a67c5f2771cf1

…-facing reply accounting Adds a test that verifies buildEmbeddedRunPayloads does not produce stale tool-error warnings when deliveredSourceReplyViaMessageTool is true but no source reply payload items are present. Without the fix in payloads.ts, hasUserFacingAssistantReply would be false, causing resolveToolErrorWarningPolicy to surface a stale warning despite the reply already being delivered via the message tool. Co-Authored-By: Claude <[email protected]>

clawsweeper · 2026-06-17T09:10:24Z

ClawSweeper review: did not complete due to Codex infrastructure failure. Reviewed June 17, 2026, 5:16 AM ET / 09:16 UTC.

Summary
Review failed before ClawSweeper could summarize the requested change.

PR surface: Source 0, Tests +20. Total +20 across 2 files.

Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path.

Review metrics: none identified.

Merge readiness
Not assessed.
Failure reason: invalid structured output.

This is a ClawSweeper/Codex infrastructure failure, not a PR readiness or patch-quality verdict.
Keep any merge decision on the normal maintainer review path until ClawSweeper can complete a fresh review.

Risk before merge

[P1] No close action taken because the review did not complete.

Maintainer options:

Decide the mitigation before merge
Retry the Codex review after fixing the execution failure.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

Review did not complete, so no work-lane recommendation was made.

Review details

Best 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 internal, reasoning high; reviewed against 5372c7146bb2.

Evidence reviewed

PR surface:

Source 0, Tests +20. Total +20 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	1	1	0
Tests	1	20	0	+20
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	21	1	+20

What I checked:

failure reason: invalid structured output.
codex failure detail: Codex review failed for this PR with exit 0 and wrote invalid JSON or schema-invalid output to /home/runner/work/clawsweeper/clawsweeper/artifacts/event/codex/93925.json: decision.rootCauseCluster fixed_by_candidate requires a canonical pull request.
codex stderr: No stderr captured.
codex stdout: eview and closure churn."},{"label":"Regression coverage","value":"1 focused payload test added","reason":"This branch covers the exact warning-accounting path that one-line-only sibling PRs do not cover."}],"labelJustifications":[{"label":"P2","reason":"This is a normal-priority user-visible Discord message accounting bug with a narrow agent payload surface."},{"label":"merge-risk: 🚨 message-delivery","reason":"The PR changes whether OpenClaw emits a channel-visible tool-error warning after message-tool-only delivery, and live transport proof is still missing."}],"itemCategory":"bug","reproductionStatus":"source_reproducible","reproductionConfidence":"high","requiresNewFeature":false,"requiresNewConfigOption":false,"requiresProductDecision":false,"reproductionAssessment":"Yes from source inspection: current main tracks deliveredSourceReplyViaMessageTool but does not count i.

Likely related people:

unknown: Codex failed before it could trace repository history. (role: review did not complete; confidence: low)

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

xydttsw · 2026-06-19T09:25:14Z

close all pr

xydttsw requested a review from a team as a code owner June 17, 2026 08:36

github-actions Bot added the dependencies-changed PR changes dependency-related files label Jun 17, 2026

xydttsw force-pushed the fix/issue-93875-discord-tool-failed-warning branch from 695484e to 1081f63 Compare June 17, 2026 08:47

openclaw-barnacle Bot added size: XS and removed cli CLI command changes scripts Repository scripts docker Docker and sandbox tooling channel: feishu Channel integration: feishu extensions: codex size: XL labels Jun 17, 2026

github-actions Bot removed the dependencies-changed PR changes dependency-related files label Jun 17, 2026

xydttsw closed this Jun 19, 2026

clawsweeper Bot mentioned this pull request Jun 21, 2026

[Bug]: Discord message_tool_only turns can append stale tool-failed warning after successful message send #93875

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

[Bug]: Discord message_tool_only turns can append stale tool-failed warning after successful message send#93925

[Bug]: Discord message_tool_only turns can append stale tool-failed warning after successful message send#93925
xydttsw wants to merge 2 commits into
openclaw:mainfrom
xydttsw:fix/issue-93875-discord-tool-failed-warning

xydttsw commented Jun 17, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 17, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 17, 2026 •

edited

Loading

Uh oh!

xydttsw commented Jun 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

xydttsw commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Real behavior proof

Uh oh!

github-actions Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Dependency graph guard cleared

Uh oh!

clawsweeper Bot commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xydttsw commented Jun 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

xydttsw commented Jun 17, 2026 •

edited

Loading

github-actions Bot commented Jun 17, 2026 •

edited

Loading

clawsweeper Bot commented Jun 17, 2026 •

edited

Loading