Conversation
Telegram's MarkdownV2 parser does not render tables — they are shown raw, with visible pipes and dashes. When the agent uses tables for structured data (comparisons, schedules, specs), the Telegram output is illegible. _convert_table() walks the outgoing text before MarkdownV2 escaping, detects table blocks (lines starting and ending with `|`, followed by a separator row `|---|---|`), and rewrites each row as a bulleted list in `**header:** value` format. Plain text outside tables is untouched. Tested on: - tables with 2-6 columns - tables with/without alignment hints (`:---`, `---:`) - text with inline pipes outside tables (no false-positive) - mixed content (multiple tables + prose in one message)
|
Thanks for the contribution and for running this in production — the approach is solid and the problem was real. This is an automated hermes-sweeper review. The underlying bug is already fixed on
The rendering approach differs (code fences vs bullet lists), and if bullet-group formatting is preferred over code-fence wrapping, the right path forward is PR #14431 which explicitly proposes that upgrade and closes issue #14160. Please feel free to coordinate there. |
Summary
_convert_table()rewrites table blocks to**header:** valuebullets before MarkdownV2 escaping.Problem
When the agent produces tables (comparisons, specs, schedules) for Telegram DMs/topics, users see this:
…rendered literally. Zero visual structure.
Fix
In
TelegramAdapter.format_text()(the hook before MarkdownV2 escaping), walk the text line-by-line. When a block of|…|rows is detected, optionally followed by a separator|---|…|:• **header:** cell(one line each)Everything else passes through unchanged.
Test plan
:---,---:,:---:) handled (separator-row regex is permissive)a | bin prose) not rewrittenNote
Patch has been carried locally in production for ~10 days. Opening upstream so it doesn't need to be rebased on every release.
🤖 Generated with Claude Code