PR #83977: fix(telegram): suppress 'accounts.default is missing' warn when defaultAccount is set (#83948)

• Repository: openclaw/openclaw
• Author: hclsys
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/83977

Description (problem / solution / changelog)

Fixes #83948.

resolveDefaultTelegramAccountSelection (extensions/telegram/src/account-selection.ts) was firing the accounts.default is missing; falling back to "<account>". Set channels.telegram.defaultAccount ... warning on every openclaw status invocation even when channels.telegram.defaultAccount was already set to a configured account. The shouldWarnMissingDefault predicate only checked whether a literal accounts.default alias existed (!accountIds.includes(DEFAULT_ACCOUNT_ID)); it did not look at channels.telegram.defaultAccount despite the warning's own remediation text instructing operators to set exactly that field. Operators who followed the advice still got the warning on every CLI invocation.

Changes

• extensions/telegram/src/account-selection.ts: hoist normalizeOptionalAccountId(cfg.channels?.telegram?.defaultAccount) ?? undefined to a local configuredDefaultAccountId const, derive hasExplicitDefaultAccount = configuredDefaultAccountId !== undefined, and gate shouldWarnMissingDefault on !hasExplicitDefaultAccount in addition to the existing 3 conditions.
• extensions/telegram/src/accounts.test.ts: regression test using the issue reporter's exact config shape — 5 accounts (hermes, charles, ops, alerts, bridge), defaultAccount: "charles", no literal accounts.default alias. Asserts the resolved account is charles and the missing-default warning does not fire.

Diff stat: 2 files, +32 / -2.

Real behavior proof

• Behavior or issue addressed: Sanitized issue evidence — the operator had channels.telegram.defaultAccount: "charles" configured with 5 accounts, routing worked correctly, but every openclaw status invocation still printed the missing-default warning recommending the field they had already set. The predicate ignored defaultAccount entirely.

• Real environment tested: Local Node 22.x. Probe at /tmp/probe_83948.mjs performs (a) source-level checks on the patched account-selection.ts (the configuredDefaultAccountId hoist, the hasExplicitDefaultAccount predicate, the final shouldWarnMissingDefault expression that combines !hasExplicitDefaultAccount with the existing 3 conditions) and (b) replays the predicate against four configurations — the issue's exact shape (5 accounts, defaultAccount=charles, first-listed account=hermes), a variant where the configured default happens to be the first-listed account (the original "warn even when defaultAccount is set" case), a no-defaultAccount + no-default-alias + multi-account case (warning still fires, no regression), and a literal-accounts.default alias case (warning suppressed in both shapes).

• Exact steps or command run after this patch: node /tmp/probe_83948.mjs

• Evidence after fix:

PASS: configuredDefaultAccountId hoisted to a local const
PASS: hasExplicitDefaultAccount predicate derived from the same source
PASS: shouldWarnMissingDefault gates on !hasExplicitDefaultAccount AND existing 3 conditions
PASS: replay (issue shape): resolved=charles, patched=NO-warn, buggy=NO-warn
PASS: replay (first-listed match): patched=NO-warn (silenced), buggy=YES-warn (confirms #83948 noise)
PASS: replay (no defaultAccount): warning still fires under patched shape (no regression)
PASS: replay (literal accounts.default present): warning suppressed in both shapes

ALL CASES PASS

• Observed result after fix: With defaultAccount configured in a multi-account telegram setup, openclaw status no longer prints the missing-default warning. Routing behavior is unchanged (the same account is selected). The diagnostic still fires for configurations that have neither a configured defaultAccount nor a literal accounts.default alias in a multi-account setup — that's the legitimate "ambiguous default" case the warning is meant for.

• What was not tested: Live openclaw status against a real 5-account telegram config — the source-level probe replays the predicate against the issue's exact shape, the vitest regression test exercises the public resolveDefaultTelegramAccountId contract with the reporter's exact 5-account + defaultAccount: "charles" config, and the existing test suite covers the unchanged paths (single account, literal alias, no defaultAccount diagnostic).

Audit (per CLAUDE rules — all 5 steps)

• Existing-helper check: Reuses the existing normalizeOptionalAccountId helper, the existing resolveListedDefaultAccountId, and the existing DEFAULT_ACCOUNT_ID constant. No new predicate. PASS
• Shared-helper caller check: resolveDefaultTelegramAccountSelection is called by resolveDefaultTelegramAccountId (same file), accounts.ts:83 (which reads shouldWarnMissingDefault), and directory-config.ts:18 (which only reads accountId). The signature is unchanged and the only behavior change is that the warning-emit gate now also requires defaultAccount to be absent — the directory-config caller is unaffected. PASS
• Broader-fix rival scan: gh pr list --search '83948 in:title,body' returns no open PRs. PASS
• Recent-merge audit: git log --oneline -10 -- extensions/telegram/src/account-selection.ts extensions/telegram/src/accounts.ts shows 16ef041b5d fix(channels): preserve implicit default accounts and c4f20b656e fix(telegram): preserve implicit default account (#82794) — both address the implicit default path (botToken / tokenFile / env var). This PR addresses the orthogonal explicit defaultAccount path; the two fixes are complementary and don't overlap. PASS
• Prototype-pollution scan: N/A — no external-input key copying.

Changed files

• extensions/telegram/src/account-selection.ts (modified, +9/-2)
• extensions/telegram/src/accounts.test.ts (modified, +23/-0)