fix(telegram): check res.ok for Markdown fallback in sendMessage#1152
fix(telegram): check res.ok for Markdown fallback in sendMessage#1152BrianYang-123 wants to merge 2 commits intoNVIDIA:mainfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughsendMessage now awaits the Telegram API response and inspects it. It first sends with Changes
Sequence DiagramsequenceDiagram
actor Caller
participant sendMessage
participant TelegramAPI
Caller->>sendMessage: sendMessage(chatId, text, replyTo)
sendMessage->>TelegramAPI: POST /sendMessage (parse_mode: "Markdown")
TelegramAPI-->>sendMessage: { ok: true, result: ... } or { ok: false, error_code, description }
alt ok === true
sendMessage-->>Caller: return result
else ok === false
alt error_code == 400 and description =~ /can't parse entities/i
sendMessage->>TelegramAPI: POST /sendMessage (no parse_mode) [retry]
TelegramAPI-->>sendMessage: { ok: true/false, result/description }
sendMessage-->>Caller: return final response
else
sendMessage-->>Caller: return original { ok: false, description }
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@scripts/telegram-bridge.js`:
- Around line 83-95: The send/retry logic around tgApi("sendMessage") should
only retry when Telegram explicitly rejects Markdown parsing: instead of
unconditionally treating any !res.ok as retryable, call tgApi for sendMessage
and inspect the response/error — if you receive an HTTP 400 with a description
containing "can't parse entities" (or similar markdown parse message) then retry
the call without parse_mode; for any other non-OK response or a
transport/network exception, rethrow or propagate the original error (do not
convert every catch into { ok: false }). Update the code paths around tgApi,
res, chunk, replyTo and chatId to perform targeted checking and only fall back
for the markdown-parse case while surfacing other errors.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ddb87539-6fa5-4e57-9b06-350a3f1d0f22
📒 Files selected for processing (1)
scripts/telegram-bridge.js
wscurran
added
bug
tgApi() resolves with {ok: false} on Telegram API errors instead of
rejecting. The existing .catch() fallback for Markdown parse failures
therefore never triggers, causing messages to be silently lost when
LLM output contains unbalanced Markdown entities (*, _, etc.).
Check res.ok explicitly so the plain-text retry actually executes.
Reproduction:
1. Send a message that triggers a long LLM response with Markdown
2. Telegram rejects with "can't parse entities" (HTTP 400, ok: false)
3. Before fix: message silently dropped, no error logged
4. After fix: automatic retry without parse_mode delivers the message
Signed-off-by: brianyang <brianyang@signalpro.com.tw>
Address review feedback: only retry without parse_mode when Telegram returns 400 with "can't parse entities", instead of retrying on all failures. This avoids masking real errors (403, 429, invalid chat). Signed-off-by: brianyang <brianyang@signalpro.com.tw>
BrianYang-123
force-pushed
the
fix/telegram-sendmessage-fallback
branch
from
feb1595 to
a866579
Compare
|
Closing — the target file Telegram message sending is now handled natively by OpenClaw inside the sandbox. Whether OpenClaw correctly retries on Markdown parse failures (error_code 400 + "can't parse entities") is unknown from NemoClaw's side. If the bug persists, it should be filed against OpenClaw. |
2 participants
Summary
Fix silent message loss when LLM output contains invalid Markdown.
Problem
tgApi()resolves with{ok: false}on Telegram API errors instead of rejecting the promise. The existing.catch()fallback for Markdown parse failures therefore never triggers, causing messages to be silently dropped with no error logged.This affects all Telegram bridge users whenever the LLM outputs unbalanced Markdown entities (
*,_, etc.), which is common with local models. Telegram returns:{"ok": false, "error_code": 400, "description": "Bad Request: can't parse entities: Can't find end of the entity starting at byte offset 1883"}But since
tgApi()resolves (not rejects),.catch()is skipped and the plain-text retry never executes.Changes
scripts/telegram-bridge.js: Checkres.okexplicitly instead of relying on.catch()for the Markdown-to-plain-text fallback.Test plan
*)Summary by CodeRabbit
Signed-off-by: brianyang brianyang@signalpro.com.tw