fix(telegram): redact bot tokens from transport error logs

[AlexFucuson9]

Summary

Telegram Bot API URLs carry credentials in the path as /bot<TOKEN>/<method>. Three error-handling paths logged raw exception text that could include these URLs, leaking bot tokens to gateway logs.

Affected Paths

Location	Function	Issue
adapter.py:1603	sendRichMessage fallback	logger.debug(... exc)
adapter.py:1709	editMessageText fallback	logger.debug(... exc)
adapter.py:1902	polling reconnect warning	logger.warning(... error)

Fix

Replace raw exc/error with _redact_telegram_error_text() in all three locations. This function already exists and uses redact_sensitive_text(force=True) from the shared redaction pipeline.

This matches the pattern already used by:

• Transient sendRichMessage failures (line 1625)
• Rich editMessageText failures (line 1721)
• Legacy send/edit retry errors (lines 3649, 3659, 3699, 3710)
• Polling error callback (line 1996)

Testing

The redaction function is already tested via agent.redact test suite. The fix ensures transport-level errors are treated consistently with all other Telegram error paths.

Fixes #58376

[alt-glitch]

This was generated by AI during triage.

Related: this closes three residual leak sites in plugins/platforms/telegram/adapter.py that the merged salvage #58501 missed — _try_send_rich fallback debug (~L1602), _try_edit_rich fallback debug (~L1707), and _schedule_polling_recovery warning (~L1899). On main, _redact_telegram_error_text() (added by #58501) is already applied at ~14 other sites but these three still pass raw exc/error, so this is a valid net-new subset fix — not a duplicate.

Related: #58376 (the issue), #58377 (earlier closed twin), #58501 (the merged salvage this completes). Note: the _schedule_polling_recovery "recovery already scheduled" debug line (~L1894) still passes raw error and is not covered by this PR.

[egilewski]

suggesting changes

The patch still leaves a Telegram transport error path logging raw bot-token URLs. In _schedule_polling_recovery(), the newly patched degraded warning redacts error, but the immediately preceding "Telegram polling recovery already scheduled" debug branch still logs the same error object directly whenever a recovery task is already pending. I reproduced this on the PR head with a synthetic pending _polling_error_task and a synthetic exception containing https://api.telegram.org/bot123456:ABCDEF_SECRET_TOKEN/sendMessage; the log output still contained both /bot123456:ABCDEF_SECRET_TOKEN/ and the raw token.

Security evidence: Telegram Bot API credentials are carried in the request path and must not reach gateway logs; _schedule_polling_recovery() can be called repeatedly for bootstrap/polling transport failures while the background recovery task is alive; this PR redacts the first warning for that path but not the same-error already-scheduled branch; the probe asserted the imported adapter came from the PR-head worktree before invoking the branch; git diff --check passed and git merge-tree succeeded, but CodeRabbit was skipped because local source validation found this residual token-log leak.

Signed: GPT-5.5-xhigh in Codex

[teknium1]

Thanks for addressing three confirmed raw-error sites. The hunks still apply cleanly to current main, but the patch needs broader coverage before it closes this transport-error leak class.

Problems

• plugins/platforms/telegram/adapter.py:2155-2159 still logs raw error when a polling recovery task is already pending. This is the same method and error object as the warning changed by this PR, so repeated recovery calls can still expose a token URL.
• plugins/platforms/telegram/adapter.py:1879-1892 catches sendRichMessageDraft transport errors and logs raw exc in both branches.
• The PR adds no regression test. tests/gateway/test_telegram_rich_messages.py:480-498 covers the transient rich-send result path, not these fallback/recovery log branches.

Suggested changes

• Apply _redact_telegram_error_text() to those sibling logging paths.
• Add caplog tests with agent.redact._REDACT_ENABLED disabled, following the force-redaction pattern at tests/gateway/test_telegram_rich_messages.py:480-498.

Automated hermes-sweeper review.

[teknium1]

This redacts the degraded warning, but the immediately preceding pending-recovery branch still logs the same error object raw. Please redact that branch too and add a force-redaction regression test for repeated recovery calls.

[teknium1]

Merged via PR #65508 — your commit was cherry-picked onto current main with your authorship preserved in git log (rebase merge, commit on main). We widened the same fix to the remaining 48 raw-exception sites in the adapter on top of your 3, so the whole class is closed. Thanks for the fix!