Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: hard NO_REPLY behavior produces bad UX in webchat after message-tool delivery [1 pull requests, 1 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#43650•Fetched 2026-04-08 00:16:23
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
WingsOfPandaWingsOfPanda
Participants
WingsOfPandaWingsOfPanda
Timeline (top)
cross-referenced ×1

When the assistant sends the real user-facing response via message(action=send) to another channel (for example Feishu), the required follow-up NO_REPLY can produce bad UX in webchat.

Root Cause

This makes cross-channel workflows feel brittle and confusing, even when the actual delivery succeeded.

Fix Action

Fixed

PR fix notes

PR #44578: fix(message-tool): surface missing delivery results

Description (problem / solution / changelog)

Summary

  • return a tool error when a send action finishes without a concrete delivery messageId
  • preserve the outbound payload details while surfacing an explicit delivery failure to the model
  • add a regression test for core send responses that produce no delivery result

Root Cause

message-tool previously fell through to jsonResult(result.payload) whenever getToolResult(result) returned nothing.

That meant a send action could look successful to the agent even when the underlying provider never produced a confirmed delivery result. In practice this can happen on best-effort / partial-failure paths, which then makes downstream logic more likely to suppress the fallback reply path or collapse into NO_REPLY-looking behavior.

Related

  • relates to #42244
  • relates to #43650
  • follows up on #717

Test Plan

  • pnpm vitest run src/agents/tools/message-tool.test.ts
  • pnpm build

Changed files

  • src/agents/tools/message-tool.test.ts (modified, +52/-0)
  • src/agents/tools/message-tool.ts (modified, +49/-1)
RAW_BUFFERClick to expand / collapse

Summary

When the assistant sends the real user-facing response via message(action=send) to another channel (for example Feishu), the required follow-up NO_REPLY can produce bad UX in webchat.

Environment

  • channel: webchat
  • cross-channel delivery to: feishu
  • main agent session

Repro

  1. Start in webchat
  2. Ask the assistant to send the result to Feishu
  3. Assistant calls message(action=send, channel=feishu, ...)
  4. Assistant then returns NO_REPLY
  5. Observe the webchat turn afterward

Expected

After successful message-tool delivery, webchat should cleanly suppress the assistant turn or otherwise handle NO_REPLY invisibly.

Actual

The post-delivery NO_REPLY behavior creates awkward/broken UX in webchat. It feels like a hard non-response after the assistant successfully completed the task elsewhere.

Why this matters

This makes cross-channel workflows feel brittle and confusing, even when the actual delivery succeeded.

Possible fix directions

  • Treat NO_REPLY as a fully suppressed control token on webchat
  • Auto-suppress the assistant turn after successful message(action=send) delivery
  • Add channel-aware handling so the originating surface does not show a broken/empty reply state

extent analysis

Fix Plan

To address the issue, we will implement a channel-aware handling mechanism to suppress the assistant turn after a successful message(action=send) delivery.

  • Modify the message function to return a flag indicating whether the response should be suppressed.
  • Update the webchat channel handler to check for this flag and suppress the assistant turn if necessary.

Example Code

def message(action, channel, **kwargs):
    # ... existing code ...
    if action == 'send' and channel != 'webchat':
        # Set a flag to suppress the response
        return {'result': 'success', 'suppress_response': True}
    # ... existing code ...

def handle_webchat_turn(message):
    if 'suppress_response' in message and message['suppress_response']:
        # Suppress the assistant turn
        return None
    # ... existing code ...

Verification

To verify the fix, follow these steps:

  • Start a conversation in webchat.
  • Ask the assistant to send a message to Feishu.
  • Verify that the assistant turn is suppressed after the message is sent.
  • Check that the webchat UI does not display a broken or empty reply state.

Extra Tips

  • Make sure to test the fix with different channels and scenarios to ensure it works as expected.
  • Consider adding logging to track when the response is suppressed to help with debugging and monitoring.

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…
#api#ssr#installation#tensor shape#autograd error#agent execution#callback error#memory management#API rate limit#retriever error

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: hard NO_REPLY behavior produces bad UX in webchat after message-tool delivery [1 pull requests, 1 participants]