Skip to content

fix(telegram): resolve env SecretRef token for status path#34297

Closed
7inspire wants to merge 2 commits intoopenclaw:mainfrom
7inspire:codex/fix-34292-telegram-status-secretref
Closed

fix(telegram): resolve env SecretRef token for status path#34297
7inspire wants to merge 2 commits intoopenclaw:mainfrom
7inspire:codex/fix-34292-telegram-status-secretref

Conversation

@7inspire
Copy link
Copy Markdown

@7inspire 7inspire commented Mar 4, 2026

Summary

Fixes #34292.

openclaw status could fail with:

channels.telegram.botToken: unresolved SecretRef "env:default:TELEGRAM_BOT_TOKEN"

even when Telegram was healthy and doctor reported OK.
Root cause: Telegram token resolution in this path treated env SecretRef as unresolved instead of resolving from process env.

What changed

  • Updated Telegram token resolution to handle env SecretRef values (source=env, provider=default) by reading process.env[ref.id].
  • Applied this to:
    • channels.telegram.botToken
    • channels.telegram.accounts.<id>.botToken
  • Kept existing behavior for unresolved refs when env value is missing.

Files

  • src/telegram/token.ts
  • src/telegram/token.test.ts

Tests

Added/updated tests to cover:

  • env SecretRef token resolves correctly when env variable is present
  • unresolved behavior remains when env variable is missing

Risk

Low, small scope:

  • Telegram token resolution path only
  • no schema/config format changes
  • no changes to other channel providers

@openclaw-barnacle openclaw-barnacle bot added channel: telegram Channel integration: telegram size: XS labels Mar 4, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 4, 2026

Greptile Summary

This PR fixes an issue where openclaw status would fail with an "unresolved SecretRef" error for channels.telegram.botToken when the token was stored as an env-source SecretRef object ({ source: "env", provider: "default", id: "..." }). The root cause was that the token resolution path called normalizeResolvedSecretInputString directly, which throws on any unresolved ref without first attempting to read from process.env.

Changes:

  • Adds a new resolveTelegramSecretInputToken helper in src/telegram/token.ts that checks whether the configured token is an env-source SecretRef with the default provider, reads from process.env[ref.id] if so, and only falls through to normalizeResolvedSecretInputString (which throws) when the env var is absent/empty. This preserves the existing error behavior for truly missing secrets.
  • Both the top-level channels.telegram.botToken and per-account channels.telegram.accounts.<id>.botToken resolution paths are updated to use the new helper.
  • New tests validate the resolved and unresolved cases for the top-level botToken.

Minor gap: The per-account botToken resolution path uses the same helper but is not covered by a dedicated test (see inline comment).

Confidence Score: 4/5

  • This PR is safe to merge — the fix is narrow in scope, logically correct, and does not affect any schema or config format.
  • The implementation correctly resolves env SecretRef tokens and preserves existing error behavior for missing env vars. The only gap is missing test coverage for the per-account botToken env SecretRef path, which is also updated by this PR.
  • src/telegram/token.test.ts — the per-account env SecretRef resolution path lacks a corresponding test.

Last reviewed commit: 6d2ce35

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 4, 2026

Additional Comments (1)

src/telegram/token.test.ts, line 158
Missing per-account env SecretRef test coverage

The PR description states the fix was applied to both channels.telegram.botToken and channels.telegram.accounts.<id>.botToken, and the implementation at line 90 of token.ts does use resolveTelegramSecretInputToken for the per-account case. However, there are no tests exercising an env SecretRef in the per-account path.

Consider adding a test analogous to the top-level one:

it("resolves per-account env SecretRef object when env var is available", () => {
  vi.stubEnv("WORK_TELEGRAM_TOKEN", "resolved-account-from-env");
  const cfg = {
    channels: {
      telegram: {
        accounts: {
          work: { botToken: { source: "env", provider: "default", id: "WORK_TELEGRAM_TOKEN" } },
        },
      },
    },
  } as unknown as OpenClawConfig;

  const res = resolveTelegramToken(cfg, { accountId: "work" });
  expect(res.token).toBe("resolved-account-from-env");
  expect(res.source).toBe("config");
});

This would confirm the fix works end-to-end for the multi-account configuration that is also called out in the PR description.

@joshavant joshavant mentioned this pull request Mar 6, 2026
Merged
@joshavant
Copy link
Copy Markdown
Contributor

joshavant commented Mar 6, 2026

Thanks for the report and the work here. This was addressed as part of a broader fix in #37023, which consolidated the related read-only SecretRef/status handling work into one implementation.

I’m closing this out as superseded by #37023 so the follow-up history stays in one place.

@joshavant joshavant closed this Mar 6, 2026
@joshavant joshavant mentioned this pull request Mar 16, 2026
Merged
20 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

channel: telegram Channel integration: telegram size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

status: unresolved SecretRef for Telegram botToken while doctor reports Telegram OK

2 participants

@7inspire @joshavant