MiniMax-AI / MiniMax-AI/minimax-code

[Bug] TELEGRAM_FORMAT escape rule produces literal backslashes in Telegram replies (incompatible with HTML outbound pipeline)

Open
#98 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug desktop needs-triage
Dominant language
TypeScript
Stars
1.3k
Forks
141
Avg merge
2h 45m
Merged PRs (30d)
46

Description

Bug

The TELEGRAM_FORMAT rule tells the LLM to escape MarkdownV2 special characters (_, *, [, ], (, ), ~, `, >, #, +, -, =, |, {, }, ., !) by prefixing them with \. The outbound pipeline (markdownToTelegramHtmlconvertInline) does NOT strip these escape sequences — it ships the reply to Telegram with parse_mode: "HTML", and the HTML parser doesn't interpret \. as ..

Result: every Telegram reply from the bot contains literal \ characters before ., !, -, (, ) throughout. Visible noise, broken formatting.

Source-level trace

Step What Where
1 TELEGRAM_FORMAT constant with "Escape special characters" rule daemon.js:67371-67380 (line 67375 is the rule itself)
2 getResponseFormatHint(platform) returns the constant daemon.js:67354-67356
3 buildInboundMetaPayload calls it, packs into response_format field daemon.js:320838-320850 (line 320841)
4 buildInboundContextPrefix wraps payload in payload._meta and emits <inbound-context>...</inbound-context> JSON daemon.js:320807-320836 (line 320813 adds _meta wrapper)
5 buildMessageParts prepends that JSON to effectiveContent (user-role message to LLM) daemon.js:320911-320916 (line 320915)
6 applySystemReminder also injects a second copy via inboundMetaProviderbuildInboundMetaBlock as # Inbound Message Context markdown daemon.js:334206-334215, daemon.js:339459-339462, daemon.js:339082-339091
7 LLM reads rule, obeys, emits \ before MarkdownV2 chars as part of output tokens (model behaviour)
8 markdownToTelegramHtmlconvertInline runs escapeHtml(processed) (line 230490) which doesn't touch \ daemon.js:230405-230504
9 sendWithFallback sends HTML to Telegram Bot API with parse_mode: "HTML" daemon.js:230761-230779
10 HTML parser doesn't know about MarkdownV2 — renders \ literally (Telegram side)

Root cause

Mismatch between instruction (LLM must add \ per MarkdownV2) and pipeline (HTML converter + Telegram HTML parser don't process MarkdownV2 escapes).

Reproduction

  1. Send any message to the bot via Telegram.
  2. Receive a reply.
  3. Observe literal \ before ., !, -, (, ) throughout.

Expected

One of:

  • LLM is not instructed to escape (narrow fix — drop the rule), OR
  • Outbound converter strips MarkdownV2 escapes before HTML conversion (wide fix — add a pass in convertInline).

Suggested fixes

Narrow (one-line): Remove line 67375 from TELEGRAM_FORMAT. LLM stops adding \, visual output is clean. Risk: minimal.

Wide: Add a pre-pass in convertInline (around line 230490, before escapeHtml) that strips \ before MarkdownV2 special chars. Rule stays valid for the day the pipeline switches to real MarkdownV2, and current HTML pipeline produces clean output.

Environment

  • Product: MiniMax Code (Mac)
  • Platform: macOS
  • Channel: Telegram (Bot API)
  • Affected component: daemon.js outbound text pipeline for Telegram

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with TELEGRAM_FORMAT and getResponseFormatHint in daemon.js, then trace convertInline and sendWithFallback through the Telegram outbound path. Reproduce the issue with a Telegram reply containing MarkdownV2 punctuation, compare the narrow and wide fixes described, and verify that the resulting HTML response no longer displays literal backslashes.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.