feat(telegram): improve remote rendering and ingress#2213
Conversation
…rkdown-rendering # Conflicts: # tests/auto-git-rollback.test.ts
|
The failing check looks like a Windows-only flaky filesystem test rather than a Telegram regression. Only I tried to rerun the failed job with Could someone with permissions rerun the failed Windows job? |
esengine
left a comment
There was a problem hiding this comment.
Re-reviewed — solid, and it closes both follow-ups I raised on #2168.
- MarkdownV2 escaping is complete and correct:
TELEGRAM_MARKDOWN_V2_SPECIAL_REcovers the full special-char set (_*[]()~>#+-=|{}.!), backslash is escaped first (right order), and code spans use a separate escaper (only` + backtick). That fixes the 'Telegram rejects unescaped text' failure mode. - Inline-button confirmations are access-controlled:
handleCallbackQuerydoesif (!this.acceptRemoteInput(userId)) returnonquery.from.id, so the fail-closed access model from #2168 extends to button presses — an unauthorized user can't tap Approve on a pending command/file/plan confirmation. - Rate limiting added (
acceptRateLimit, 5 msgs/window) — exactly the queue-bounding I asked for.
CI is green now (the earlier failure was a flaky Windows directory_tree timeout, unrelated — it passed on re-run). Merging.
Two non-blocking notes for a later pass: (1) confirmation callbackData is just "1" — fine while confirmations are serialized one-at-a-time, but if concurrent confirmations ever become possible it'd need a confirmation id; (2) consider correlating the press to the originating message_id so a stale button from an old confirmation can't approve a newer one.
Summary
Review Follow-up
This PR includes follow-up fixes for the non-blocking items called out in #2168 (review):
401) and polling conflicts (409). The same sanitization is used for initialization, polling, command registration, callback acknowledgements, and sendMessage failures.Verification
npm run verify