fix(#82957): route Telegram polling [diag] lines through info channel, not error#83047
Closed
YonganZhang wants to merge 1 commit into
Closed
Conversation
… channel, not error
`extensions/telegram/src/monitor.ts:111` previously hard-coded:
const log = opts.runtime?.error ?? console.error;
so every line emitted by the monitor and every line bubbled from
`TelegramPollingSession.opts.log` ended up on the runtime's error
channel. Normal lifecycle diagnostics ("polling cycle started",
"rebuilding transport for next polling cycle", "waited for previous
polling session", etc.) were therefore styled as gateway errors in the
console, breaking the visual distinction between expected lifecycle
output and actual failures.
`[telegram][diag]` is the established info-level marker in this
extension. polling-session.ts:260 itself wraps incoming `info: ...`
messages into `[telegram][diag] ${msg}` before forwarding, confirming
the intent. Other extensions (twitch monitor.ts:193,
nextcloud-talk room-info.ts:105, zalo monitor.webhook.ts:146,
signal daemon.ts:96, feishu card-action.ts:155/298) consistently use
`runtime?.log` for info and `runtime?.error` for error.
Fix: split the single `log` into a dispatch that picks the channel
based on the `[telegram][diag]` prefix:
const logInfo = opts.runtime?.log ?? console.log;
const logError = opts.runtime?.error ?? console.error;
const log = (line: string) =>
(line.includes("[telegram][diag]") ? logInfo : logError)(line);
After this change, lines like "polling cycle started ..." land on the
info channel; only true failures ("Restarting polling after ...",
"reconnect delivery drain failed: ...") stay on error.
Contributor
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close as duplicate/superseded: an earlier open maintainer-labeled PR for the same Telegram log-level bug already changes the same monitor boundary and adds regression coverage, so this parallel branch does not carry unique work that should remain open. Canonical path: Use #82958 as the canonical path to finish and land the Telegram logger fix, then let it close the linked issue. So I’m closing this here and keeping the remaining discussion on #82958 and #82957. Review detailsBest possible solution: Use #82958 as the canonical path to finish and land the Telegram logger fix, then let it close the linked issue. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection shows current main binds the Telegram monitor logger to Is this the best way to solve the issue? No, not as a separate PR. The log-channel direction is sound, but the earlier open canonical PR covers the same bug and adds regression coverage, so this duplicate branch is not the best landing path. Security review: Security review cleared: The diff only changes local Telegram log dispatch in one source file and does not touch dependencies, CI, secrets, permissions, or code execution paths. What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 2ab76240d308. |
25 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #82957.
extensions/telegram/src/monitor.ts:111previously hard-coded:so every line emitted by the monitor and every line bubbled from
TelegramPollingSession.opts.logended up on the runtime's error channel. Normal lifecycle diagnostics ("polling cycle started", "rebuilding transport for next polling cycle", "waited for previous polling session", etc.) were therefore styled as gateway errors in the console, breaking the visual distinction between expected lifecycle output and actual failures.Why
[telegram][diag]is the right discriminator[telegram][diag]is the established info-level marker in this extension.polling-session.ts:260itself wraps incominginfo: ...messages into\[telegram][diag] ${msg}before forwarding — confirming the intent. Other extensions are consistent:twitch/src/monitor.ts:193,195info: (msg) => runtime.log?.(msg)error: (msg) => runtime.error?.(msg)nextcloud-talk/src/room-info.ts:105runtime?.log?.(...)zalo/src/monitor.webhook.ts:146log: runtime?.logsignal/src/daemon.ts:96opts.runtime?.log ?? (() => {})feishu/src/card-action.ts:155, 298runtime?.log ?? console.logTelegram is the outlier — fixing it brings it in line.
Fix
The single-
logAPI exposed downstream (notablyPollingSessionOpts.log) is unchanged — callers still calllog("anything"), but now[diag]lines route to info.Real behavior proof
Diagnostics now land on the info channel; only true failures stay on error — matching the issue's expected behavior verbatim.
Diff size
7 lines (3 changed, 4 added comment+dispatch). Single file. No new dependencies.