fix(#82957): route Telegram polling [diag] lines through info channel, not error

YonganZhang · YonganZhang · commit 38552000554d · 2026-05-17T18:19:01.000+08:00
`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) =&gt;
      (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.
diff --git a/extensions/telegram/src/monitor.ts b/extensions/telegram/src/monitor.ts
@@ -108,7 +108,17 @@ async function loadTelegramMonitorWebhookRuntime() {
 }
 
 export async function monitorTelegramProvider(opts: MonitorTelegramOpts = {}) {
-  const log = opts.runtime?.error ?? console.error;
+  // `[telegram][diag] ...` lines are normal lifecycle diagnostics (polling
+  // cycle start, transport rebuild, lease wait, etc.) — they were previously
+  // routed through `runtime.error`, so normal startup looked like a gateway
+  // error in the console. Route the diagnostic prefix through the info
+  // channel (matching twitch / polling-session / zalo conventions), keep the
+  // raw `runtime.error` path for genuine failures.
+  // Fixes #82957.
+  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);
   let pollingSession: TelegramPollingSessionInstance | undefined;
 
   const handlePollingNetworkFailure = (err: unknown, label: string) => {
