openclaw - 💡(How to fix) Fix [Bug]: registerCommand handler: no way to suppress "No response generated" when plugin owns its own transport send

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…

Version: 2026.5.10-beta.5 (1ba6893) Platform: Windows 11

Summary: Plugin commands registered via api.registerCommand that send responses directly via Telegram Bot API (with custom retry logic and IPv4 forcing) trigger "No response generated. Please try again." from the Telegram channel adapter after every command, because the handler returns undefined.

Expected: A way to tell OpenClaw "handler took care of delivery, suppress the fallback" — e.g. return { handled: true } or return { suppressReply: true }.

Actual: No such return value exists in beta.5. Returning undefined, {}, or { continueAgent: false } all produce the fallback message.

Why plugins own their own transport: Some plugins need custom send logic (retry loops, IPv4 family forcing, chunked messages, Markdown escaping) that isn't available through the return payload path. Forcing these plugins to return { text: "..." } and use OpenClaw's delivery path loses those transport guarantees.

Request: Add { suppressReply: true } or { handled: true } as a valid registerCommand handler return to silence the fallback without sending a second message.

Confirmed with krill in Discord that this is a known gap and worth filing.

Root Cause

Summary: Plugin commands registered via api.registerCommand that send responses directly via Telegram Bot API (with custom retry logic and IPv4 forcing) trigger "No response generated. Please try again." from the Telegram channel adapter after every command, because the handler returns undefined.

Fix Action

Fix / Workaround

Request: Add a first-class silent result for registerCommand handlers that own their own transport delivery:

  • return { suppressReply: true } — suppress fallback, send nothing
  • or return { handled: true } — same semantics as before_dispatch
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Version: 2026.5.10-beta.5 (1ba6893) Platform: Windows 11

Summary: Plugin commands registered via api.registerCommand that send responses directly via Telegram Bot API (with custom retry logic and IPv4 forcing) trigger "No response generated. Please try again." from the Telegram channel adapter after every command, because the handler returns undefined.

Expected: A way to tell OpenClaw "handler took care of delivery, suppress the fallback" — e.g. return { handled: true } or return { suppressReply: true }.

Actual: No such return value exists in beta.5. Returning undefined, {}, or { continueAgent: false } all produce the fallback message.

Why plugins own their own transport: Some plugins need custom send logic (retry loops, IPv4 family forcing, chunked messages, Markdown escaping) that isn't available through the return payload path. Forcing these plugins to return { text: "..." } and use OpenClaw's delivery path loses those transport guarantees.

Request: Add { suppressReply: true } or { handled: true } as a valid registerCommand handler return to silence the fallback without sending a second message.

Confirmed with krill in Discord that this is a known gap and worth filing.

Steps to reproduce

Steps to reproduce:

  1. Register a command via api.registerCommand with a handler that sends a response directly via Telegram Bot API and returns undefined
  2. Send the slash command from Telegram
  3. Handler executes successfully and delivers the response via Bot API
  4. OpenClaw sends a second message: "No response generated. Please try again."

Minimal example:

name: "pulse",
description: "Liveness check",
acceptsArgs: false,
async handler(ctx) {
const chatId = telegramChatId(ctx.to ?? ctx.from);
await sendViaBotAPI(chatId, "✅ OK");
// returns undefined
},
});

### Expected behavior

**Expected behavior:**
Handler delivers the response. OpenClaw suppresses the fallback. 
User sees exactly one message.

### Actual behavior

**Actual behavior:**
User sees two messages: the correct handler response, then 
"No response generated. Please try again."

### OpenClaw version

2026.5.10-beta.5 (1ba6893)

### Operating system

Windows 11 Pro (win32 x64)

### Install method

npm install -g [email protected]

### Model

**Model:** anthropic/claude-sonnet-4-6 (primary) **Model routing:** Gemini 2.5 Flash-Lite for boot acknowledgment and  non-procurement triage; Haiku for lightweight calls; Sonnet for  email drafting, document review, BCC extraction **Note:** Issue is not model-dependent — registerCommand handlers that  return undefined trigger the fallback regardless of whether a model  call occurred

### Provider / routing chain

**Provider / routing chain:** Telegram inbound → registerCommand handler → Telegram Bot API direct send  (custom https.request with IPv4 forcing + retry loop) → returns undefined  → OpenClaw Telegram channel adapter sends fallback

### Additional provider/model setup details

**Request:**
Add a first-class silent result for registerCommand handlers that own 
their own transport delivery:
- `return { suppressReply: true }` — suppress fallback, send nothing
- or `return { handled: true }` — same semantics as before_dispatch

Confirmed with krill in Discord as a known gap worth filing.

**Why the plugin owns transport:**
Custom send logic required: IPv4 family forcing (`family: 4`) to avoid 
Happy Eyeballs dual-stack failure on Windows, 3-attempt retry with 
exponential backoff, chunked message splitting for long responses, 
MarkdownV1 escaping. These aren't available through the return payload path.

### Logs, screenshots, and evidence

```shell

Impact and severity

Medium. Commands work correctly — this is cosmetic noise that erodes user trust ("Please try again" implies failure when there was none). Every command produces a spurious failure message.

Additional information

No response

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…

FAQ

Expected behavior

Expected behavior: Handler delivers the response. OpenClaw suppresses the fallback. User sees exactly one message.

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 - 💡(How to fix) Fix [Bug]: registerCommand handler: no way to suppress "No response generated" when plugin owns its own transport send