hermes - ✅(Solved) Fix Telegram output leaks raw LaTeX-style sequences like \rightarrow; frequent with gemma-4-31b-it [1 pull requests]

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…

Root Cause

From the current code path:

  • gateway/run.py reads final_response directly from the agent result.
  • gateway/platforms/telegram.py calls format_message(content) before sending.
  • TelegramAdapter.format_message() handles MarkdownV2 conversion / escaping.
  • There is no Telegram-side LaTeX/plain-text normalization stage before MarkdownV2 formatting.

So if the model emits raw LaTeX-like text, the gateway preserves it and Telegram sends it as-is.

Fix Action

Fixed

PR fix notes

PR #13275: fix(telegram): normalize LaTeX-style sequences to Unicode in format_message

Description (problem / solution / changelog)

Fixes #13262

Problem

Raw LaTeX-style escape sequences (e.g., \\rightarrow, \\alpha) leak into Telegram messages when models like gemma-4-31b-it emit mathematical notation. Users see raw backslash macros instead of readable Unicode.

Solution

Added _normalize_latex() function that converts 120+ common LaTeX macros to their Unicode equivalents before MarkdownV2 formatting. The normalization runs as the first step in format_message(), ensuring LaTeX sequences are converted before any Telegram-specific escaping.

Coverage

  • Arrows: \\rightarrow, \\leftarrow, \\leftrightarrow, \\Rightarrow, \\Leftarrow
  • Comparison: \\leq, \\geq, \\neq, \\approx, \\equiv
  • Arithmetic: \\times×, \\div÷, \\pm±, \\cdot·
  • Logic/Set: \\land, \\lor, \\in, \\notin, \\subset, \\supset, \\cup, \\cap, \\forall, \\exists, \\emptyset
  • Calculus: \\infty, \\partial, \\nabla, \\sumΣ, \\prodΠ, \\int, \\sqrt
  • Greek: Full lowercase (\\alpha\\omega) and uppercase (\\Gamma, \\Delta, \\Theta, \\Lambda, \\Xi, \\Pi, \\Sigma, \\Phi, \\Psi, \\Omega)
  • Misc: \\ldots, \\cdots, \\degree°

Safety

  • Uses word-boundary regex (\\b) to avoid matching partial words (e.g., "alphabet" is not affected)
  • Only processes standalone backslash sequences, not escaped backslashes (\\\\)
  • All 17 test cases pass

Test Results

\\rightarrow → → ✓
\\alpha → α ✓
\\leq → ≤ ✓
\\infty → ∞ ✓
alphabet → alphabet ✓ (protected)
A \\rightarrow B \\leq C → A → B ≤ C ✓

Changed files

  • gateway/platforms/telegram.py (modified, +198/-0)
  • gateway/run.py (modified, +13/-1)
RAW_BUFFERClick to expand / collapse

Problem

When Hermes sends Telegram replies, raw LaTeX-style escape sequences can leak into the final user-visible message instead of being normalized to plain text.

A frequent real-world trigger is the gemma-4-31b-it model, which often emits \\rightarrow-style output in normal prose / structured explanations. Hermes currently forwards that content through the Telegram formatting pipeline without a LaTeX-to-plain-text normalization step, so users see raw backslash macros in Telegram.

This is not just a prompt-quality issue. It is a delivery-pipeline issue.

Reproduction

  1. Use Hermes through the Telegram gateway.
  2. Use a model such as gemma-4-31b-it.
  3. Ask for a structured explanation / flow / step-by-step reasoning where the model is likely to emit arrow-like notation.
  4. The final Telegram message may contain raw sequences like \\rightarrow instead of a plain-text arrow or equivalent normalized text.

Actual behavior

Telegram users receive raw LaTeX-style sequences in plain-text chat output.

Example:

  • A \\rightarrow B

Expected behavior

Telegram delivery should normalize LaTeX-style text before MarkdownV2 escaping / sending.

Example expected output:

  • A → B
  • or A -> B

Root cause analysis

From the current code path:

  • gateway/run.py reads final_response directly from the agent result.
  • gateway/platforms/telegram.py calls format_message(content) before sending.
  • TelegramAdapter.format_message() handles MarkdownV2 conversion / escaping.
  • There is no Telegram-side LaTeX/plain-text normalization stage before MarkdownV2 formatting.

So if the model emits raw LaTeX-like text, the gateway preserves it and Telegram sends it as-is.

Why this matters

This is reproducible with real models, especially gemma-4-31b-it, and it affects plain-text messaging UX directly. Users should not need prompt hacks or per-user behavioral constraints to avoid raw transport-visible escape sequences.

Proposed fix

Add a deterministic content-normalization stage before Telegram MarkdownV2 formatting.

Suggested order:

  1. Normalize common LaTeX-style symbols / wrappers to plain text.
  2. Then run Telegram MarkdownV2 conversion / escaping.

A minimal version could map common macros such as:

  • \\rightarrow ->
  • \\leftarrow ->
  • \\Rightarrow ->

Potential insertion point:

  • very early in gateway/platforms/telegram.py:TelegramAdapter.format_message()
  • or as a shared gateway-level normalization utility used by messaging adapters

Related issues

This appears related in family to existing Telegram / message-formatting issues such as:

  • #6388 Telegram MarkdownV2 escape breaks bullet list display
  • earlier Telegram formatting / escaping bugs already fixed in this repo

Environment

  • Hermes Agent version: 0.10.0
  • Platform: Telegram
  • Model frequently triggering this: gemma-4-31b-it

extent analysis

TL;DR

Add a LaTeX-to-plain-text normalization stage before Telegram MarkdownV2 formatting to prevent raw LaTeX-style escape sequences from leaking into user-visible messages.

Guidance

  • Identify the potential insertion points for the normalization stage, such as gateway/platforms/telegram.py:TelegramAdapter.format_message() or a shared gateway-level normalization utility.
  • Develop a mapping of common LaTeX-style symbols to their plain-text equivalents, including \\rightarrow -> , \\leftarrow -> , and \\Rightarrow -> .
  • Consider implementing a deterministic content-normalization stage that can handle various LaTeX-style input and produce consistent plain-text output.
  • Verify the proposed fix by testing it with the gemma-4-31b-it model and other models that frequently emit LaTeX-style output.

Example

A minimal implementation of the LaTeX-to-plain-text normalization stage could involve creating a dictionary that maps LaTeX-style symbols to their plain-text equivalents:

latex_to_plain_text = {
    '\\rightarrow': '→',
    '\\leftarrow': '←',
    '\\Rightarrow': '⇒'
}

def normalize_latex(content):
    for latex, plain_text in latex_to_plain_text.items():
        content = content.replace(latex, plain_text)
    return content

Notes

The proposed fix assumes that the LaTeX-style output from the models is consistent and can be reliably mapped to plain-text equivalents. Additional testing and refinement may be necessary to handle edge cases or unexpected input.

Recommendation

Apply the proposed workaround by adding a LaTeX-to-plain-text normalization stage before Telegram MarkdownV2 formatting, as it directly addresses the identified root cause and provides a clear path to resolving the issue.

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

Telegram delivery should normalize LaTeX-style text before MarkdownV2 escaping / sending.

Example expected output:

  • A → B
  • or A -> B

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix Telegram output leaks raw LaTeX-style sequences like \rightarrow; frequent with gemma-4-31b-it [1 pull requests]