openclaw - ✅(Solved) Fix Cron delivery ignores threadId for Telegram forum topics [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#43695Fetched 2026-04-08 00:17:04
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1

Fix Action

Fix / Workaround

Workaround: Have the cron job task explicitly send via the message tool instead of relying on announce delivery.

PR fix notes

PR #43808: cron: honor delivery.threadId for Telegram announce delivery

Description (problem / solution / changelog)

Summary

  • Problem: isolated cron announce delivery accepted delivery.threadId in job config, but the cron delivery plan/target plumbing never carried that field into outbound delivery.
  • Why it matters: Telegram forum-topic cron jobs fell back to General instead of the configured topic unless users encoded :topic: into delivery.to or routed through the message tool as a workaround.
  • What changed: added delivery.threadId to the cron delivery contract, normalized/preserved it on create/update, and threaded it into isolated announce target resolution.
  • What did NOT change (scope boundary): webhook delivery, failure-destination routing, and legacy payload delivery hints were left unchanged.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • 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 #43695
  • Related #43469

User-visible / Behavior Changes

  • Isolated cron announce jobs now honor delivery.threadId for threaded channels such as Telegram forum topics.
  • delivery.threadId is trimmed on create/update and preserved when other delivery fields are edited.

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: Node 25.2.1, Bun 1.3.5
  • Model/provider: N/A
  • Integration/channel (if any): Telegram
  • Relevant config (redacted):
"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "-1003700845925",
  "threadId": "15",
  "bestEffort": true
}

Steps

  1. Create or edit an isolated cron job with announce delivery targeting a Telegram forum chat and set delivery.threadId to a non-General topic id.
  2. Force-run the cron job.
  3. Observe where the summary message lands.

Expected

  • The summary is delivered to the configured Telegram topic/thread.

Actual

  • Before this change, cron announce delivery ignored delivery.threadId, so the message landed in the default General topic.

Evidence

Attach at least one:

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

Post-patch normalization/merge checks:

{"mode":"announce","channel":"telegram","to":"-1003816714067","threadId":"15"}
{"mode":"announce","channel":"telegram","to":"-100123","threadId":"15"}

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • bunx vitest run src/cron/normalize.test.ts src/cron/service.jobs.test.ts
    • Manual node --import tsx checks confirming delivery.threadId is normalized on create and preserved by applyJobPatch.
  • Edge cases checked:
    • Blank delivery.threadId is stripped.
    • Updating delivery.to preserves an existing delivery.threadId.
    • Existing :topic:-based topic routing coverage remains in place, and this PR adds explicit delivery.threadId regression coverage.
  • What you did not verify:
    • In this local workspace, the heavier Vitest files that import the cron delivery runtime (src/cron/delivery.test.ts, src/cron/isolated-agent.delivery-target-thread-session.test.ts, src/cron/isolated-agent.direct-delivery-forum-topics.test.ts) hung after RUN ... without producing a failure, so I could not complete those locally.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
    • Revert commit 28de381c8, or omit delivery.threadId and keep using delivery.to: "<chatId>:topic:<topicId>" / the message-tool workaround.
  • Files/config to restore:
    • src/cron/types.ts
    • src/cron/delivery.ts
    • src/cron/isolated-agent/delivery-target.ts
    • src/cron/isolated-agent/run.ts
    • src/cron/normalize.ts
    • src/cron/service/jobs.ts
  • Known bad symptoms reviewers should watch for:
    • Cron announce delivery landing in the wrong Telegram topic.
    • Job edits unexpectedly clearing an existing delivery.threadId.

Risks and Mitigations

  • Risk:
    • Threaded delivery behavior could change for channels that start consuming delivery.threadId from cron config.
  • Mitigation:
    • The value is only forwarded when explicitly configured, blank values are normalized away, and the patch adds create/update regression coverage around the new field.

Changed files

  • src/cron/delivery.test.ts (modified, +45/-0)
  • src/cron/delivery.ts (modified, +19/-0)
  • src/cron/isolated-agent.delivery-target-thread-session.test.ts (modified, +14/-0)
  • src/cron/isolated-agent.delivery.test-helpers.ts (modified, +1/-0)
  • src/cron/isolated-agent.direct-delivery-forum-topics.test.ts (modified, +25/-1)
  • src/cron/isolated-agent/delivery-target.ts (modified, +5/-0)
  • src/cron/isolated-agent/run.ts (modified, +1/-0)
  • src/cron/normalize.test.ts (modified, +15/-0)
  • src/cron/normalize.ts (modified, +12/-0)
  • src/cron/service.jobs.test.ts (modified, +20/-0)
  • src/cron/service/jobs.ts (modified, +11/-0)
  • src/cron/types.ts (modified, +2/-0)
  • src/gateway/protocol/schema/cron.ts (modified, +1/-0)
  • src/gateway/server.cron.test.ts (modified, +63/-0)

Code Example

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "-1003700845925",
  "threadId": "15",
  "bestEffort": true
}
RAW_BUFFERClick to expand / collapse

Version: OpenClaw 2026.3.8 (3caab92)

Bug: Cron job delivery with threadId in the delivery config doesn't respect the thread — messages land in General (topic 1) instead of the specified topic.

Cron config:

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "-1003700845925",
  "threadId": "15",
  "bestEffort": true
}

Expected: Message delivered to topic 15 (System) Actual: Message delivered to topic 1 (General)

Note: The message tool with threadId works correctly — same chat, same threadId, message lands in the right topic. Only cron delivery is affected.

Workaround: Have the cron job task explicitly send via the message tool instead of relying on announce delivery.

extent analysis

Fix Plan

To resolve the issue with cron job delivery not respecting the specified thread, we need to modify the cron job configuration to use the message tool instead of announce delivery.

Steps

  • Update the cron job configuration to use the message tool:
"delivery": {
  "mode": "message",
  "channel": "telegram",
  "to": "-1003700845925",
  "threadId": "15",
  "bestEffort": true
}

Alternatively, if the announce mode is required, we can create a custom script that uses the message tool to send the message to the specified thread:

# Send message via message tool
message -c telegram -t -1003700845925 -d 15 "Message content"
  • If using a custom script, update the cron job to run the script instead of relying on the announce delivery.

Verification

To verify that the fix worked, run the cron job and check that the message is delivered to the correct topic (in this case, topic 15, System).

Extra Tips

  • Ensure that the message tool is properly configured and working as expected.
  • If issues persist, check the cron job logs for any errors or warnings related to the message tool or thread ID.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Cron delivery ignores threadId for Telegram forum topics [1 pull requests, 1 participants]