fix(telegram): escape MarkdownV2 reserved parens in chunk indicators (#74004) - #74028
fix(telegram): escape MarkdownV2 reserved parens in chunk indicators (#74004)#74028kyssta-exe wants to merge 1 commit into
Conversation
|
One remaining parity gap with the live adapter: this copies the indicator escaping but omits |
|
The fix works for the main case, and the approach checks out: this is the same regex the gateway adapter already uses for this exact bug ( Two things before this merges:
No regressions on my read. The change is scoped to MarkdownV2 multi-chunk sends, and a false positive can't really happen since user parens are already escaped by the time the indicator is appended. Small nit: |
|
Thanks for addressing the standalone sender path. The ordinary MarkdownV2 suffix escape is the right direction, but this needs one parity fix before it is complete. Problems
Suggested changes
Automated hermes-sweeper review. |
Problem
When a Telegram message is sent via the standalone
_send_telegram()path and is long enough to be chunked (>4096 UTF-16 units),BasePlatformAdapter.truncate_message()appends chunk indicators like(1/3)to each chunk. These parentheses are reserved characters in Telegram's MarkdownV2 format and cause the API to reject the message, falling back to plain text — silently stripping all formatting.Fix
After chunking, escape the parentheses in chunk indicators when the parse mode is MarkdownV2. The pattern
r' (\d+)/(\d+)\)$'targets only the(N/M)suffix appended bytruncate_message()at the end of each chunk and wraps the parentheses with MarkdownV2 escapes (\(,\)).Testing
The fix was verified with a Python unit test:
**bold** message (1/3)→ Output:**bold** message \(1/3\)Closes #74004