PR #70814: fix(cron): accept numeric telegram announce chat ids (Fixes #70758)

• Repository: openclaw/openclaw
• Author: deepujain
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/70814

Description (problem / solution / changelog)

Summary

• Problem: cron announce delivery can treat a numeric Telegram chat ID as delivery.channel, which later fails with Unsupported channel: <chatId>.
• Why it matters: Telegram cron jobs that should deliver to a direct chat or group chat ID can finish the run but drop the announce step.
• What changed: when delivery.channel is not actually a channel and there is no separate delivery.to, cron delivery now reuses the sole configured announce channel and treats that value as the explicit target; I also added regressions for both the plain --to 834732674 path and the misplaced delivery.channel=834732674 path.
• What did NOT change (scope boundary): this does not add broad multi-channel guessing. If channel selection is ambiguous, the resolver still leaves that case alone instead of guessing.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #70758
• Related #70574
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the cron delivery resolver accepted any lowercased string in delivery.channel long enough for a raw Telegram chat ID to survive as the channel value instead of being treated as the destination.
• Missing detection / guardrail: there was no regression coverage for a numeric Telegram target reaching cron delivery either through delivery.to or through a misfiled delivery.channel value when only one announce channel is configured.
• Contributing context (if known): gateway validation intentionally allows raw channel values when there is only one configured announce channel, so the runtime resolver needs to recover cleanly from that shape.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cron/isolated-agent/delivery-target.test.ts
• Scenario the test should lock in: numeric Telegram-style IDs resolve through the sole configured announce channel both when passed in delivery.to and when the same value lands in delivery.channel.
• Why this is the smallest reliable guardrail: the bug is in the delivery target resolver, so the resolver test exercises the exact normalization and fallback path without pulling in unrelated cron execution behavior.
• Existing test that already covers this (if any): none that covered the numeric-target path.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Isolated cron jobs with Telegram announce delivery can now keep numeric chat IDs as valid targets instead of failing with Unsupported channel.
• Stored cron jobs that accidentally carry the numeric Telegram chat ID in delivery.channel now recover when there is exactly one configured announce channel.

Diagram (if applicable)

Before:
[cron delivery config with numeric Telegram target]
  -> [resolver keeps numeric value as channel]
  -> [outbound target resolution]
  -> [Unsupported channel: 834732674]

After:
[cron delivery config with numeric Telegram target]
  -> [resolver recognizes "not a real channel" when only one announce channel exists]
  -> [reuse that channel + move numeric value to explicit target]
  -> [announce delivery proceeds]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local worktree at /tmp/openclaw-70758-worktree
• Model/provider: N/A
• Integration/channel (if any): Telegram-style cron delivery target resolution
• Relevant config (redacted): one configured announce channel in the validation harness

Steps

1. Resolve cron delivery with channel: "last" and to: "834732674" while exactly one announce channel is configured.
2. Resolve cron delivery again with channel: "834732674" and no to while the same single announce channel is configured.
3. Confirm both cases resolve to that announce channel with to: "834732674".

Expected

• Numeric Telegram chat IDs stay usable as announce targets.

Actual

• Before the fix, the misplaced-channel path could surface Unsupported channel: 834732674.
• After the fix, both resolver cases return the configured channel plus to: "834732674".

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Direct runtime harness output after the fix:

{"name":"explicit-to","ok":true,"channel":"alpha","to":"834732674"}
{"name":"misplaced-channel","ok":true,"channel":"alpha","to":"834732674"}

I also tried pnpm test -- src/cron/isolated-agent/delivery-target.test.ts, but the local Vitest lane aborts before test execution on this machine because the repo wants Node >=22.14.0 and the worktree is currently running Node 22.12.0.

Human Verification (required)

• Verified scenarios: both numeric-target resolver paths above using a direct tsx harness against the real delivery resolver.
• Edge cases checked: the recovery only kicks in when there is no separate delivery.to and channel selection collapses to one configured announce channel.
• What you did not verify: a full Vitest run in this worktree, because the local Node version is below the repo's declared minimum and the runner crashes before loading the file.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: a non-channel delivery.channel value could be interpreted too aggressively.
  • Mitigation: the recovery only applies when there is no separate delivery.to and channel selection resolves to exactly one configured announce channel, so multi-channel setups are not guessed.

Changed files

• src/cron/isolated-agent/delivery-target.test.ts (modified, +33/-0)
• src/cron/isolated-agent/delivery-target.ts (modified, +29/-2)