PR #44859: Cron: Add additional targets that result of cron jobs will be sent to multiple channels

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

Description (problem / solution / changelog)

Summary

• Problem: Cron jobs could only deliver their output to a single channel/recipient; there was no built-in way to fan-out the same result to multiple destinations simultaneously. Additionally, the Discord channel plugin was missing session-routing utilities needed for correct outbound session-key resolution, and commands-session.ts eagerly initialized the plugin runtime at module load time, which could crash at startup when channel plugins were not yet available.
• Why it matters: Teams that monitor activity across multiple channels (e.g. Telegram + Discord + Signal) had to create duplicate cron jobs for each destination, duplicating configuration and increasing scheduling overhead.
• What changed:
  • Added additionalTargets field to CronDelivery — an array of { channel, to, accountId? } entries that receive the same payloads after the primary delivery succeeds. Each target is resolved and delivered independently; one failure does not block the others.
  • Added deliverToAdditionalTargets() in src/cron/isolated-agent/delivery-dispatch.ts and wired it into the cron run pipeline in src/cron/isolated-agent/run.ts.
  • Added normalization and validation of additionalTargets in src/cron/normalize.ts (trims/lowercases channel, trims to, strips blank accountId, filters out entries missing either required field).
  • Imported buildAgentSessionKey, resolveThreadSessionKeys, and RoutePeer from openclaw/plugin-sdk/routing into extensions/discord/src/channel.ts to fix outbound session-key construction for Discord.
  • Changed channelRuntime in src/auto-reply/reply/commands-session.ts from an eager module-level constant to a lazy getChannelRuntime() accessor, preventing plugin runtime initialization at import time.
• What did NOT change: Primary delivery behavior, failure-destination logic, cron scheduling, and all other channel plugins are unmodified.

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

• Related #

AI/Vibe-Coded PRs

• Mark as AI-assisted in the PR title or description
• Note the degree of testing : fully tested
• Confirm you understand what the code does: Yes

User-visible / Behavior Changes

New delivery.additionalTargets field for cron jobs. After the primary delivery completes, the same output payloads are sent to each additional target. Example:

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "123456789",
  "additionalTargets": [
    { "channel": "signal", "to": "+15550001111" },
    { "channel": "discord", "to": "channel-456", "accountId": "bot-b" }
  ]
}

• Fan-out is best-effort per target: a failure on one target is logged and skipped; remaining targets still receive delivery.
• bestEffort from the primary delivery is inherited by all additional targets.
• Invalid entries (empty channel or to, blank accountId) are silently filtered at normalization time.

Security Impact (required)

• New permissions/capabilities? Yes — cron jobs can now deliver to additional channel targets, increasing the outbound delivery surface.
• Secrets/tokens handling changed? No
• New/changed network calls? Yes — each additional target results in an outbound messaging call using the existing deliverOutboundPayloads path, which already applies SSRF and channel-allowlist policies.
• Command/tool execution surface changed? No
• Data access scope changed? No
• Risk + mitigation: Fan-out reuses the existing resolveDeliveryTarget + deliverOutboundPayloads stack, so all existing allowlist, SSRF, and auth checks apply to each additional target identically. No new bypass paths are introduced.

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Node 22 / Bun
• Model/provider: any
• Integration/channel: Telegram, Signal, Discord
• Relevant config (redacted): delivery.additionalTargets in a cron job

Steps

1. Create a cron job with delivery.mode = "announce", a primary channel/to, and an additionalTargets array containing two entries (e.g. Signal + Discord).
2. Trigger the job manually or wait for its scheduled run.
3. Confirm the primary channel receives the output.
4. Confirm each additional target also receives the same output.
5. Disable one additional target's channel to confirm the other target still receives delivery and the job does not fail.

Expected

• Primary delivery succeeds.
• Each additional target independently receives the same payloads.
• A failing additional target logs a warning and does not affect other targets or the run outcome.

Actual

• Matches expected in all three cases.

Evidence

• Failing test/log before + passing after — new unit tests in src/cron/isolated-agent/delivery-dispatch.additional-targets.test.ts cover: successful fan-out, target-resolution failure isolation, delivery failure isolation, accountId forwarding, empty targets array, and bestEffort flag propagation.
• Normalization tests in src/cron/normalize.test.ts cover: valid targets, casing/trimming, invalid-entry filtering, empty-array cleanup, and blank accountId stripping.

Human Verification (required)

• Verified scenarios: fan-out to two additional targets (Telegram + Signal); one target failing does not block the other; bestEffort is correctly inherited.
• Edge cases checked: empty additionalTargets array is treated as no-op; targets with blank accountId are normalized correctly; primary delivery failure prevents fan-out (fan-out runs only after primary succeeds).
• What you did not verify: webhook-mode additional targets; more than three simultaneous additional targets under real network load.

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 — additionalTargets is optional; existing cron jobs without it are unaffected.
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Remove additionalTargets from the affected cron job's delivery config via openclaw cron edit <jobId>.
• Files/config to restore: src/cron/types.ts, src/cron/normalize.ts, src/cron/isolated-agent/delivery-dispatch.ts, src/cron/isolated-agent/run.ts.
• Known bad symptoms reviewers should watch for: [additional-delivery] warn lines appearing in gateway logs for targets that were expected to succeed; primary delivery being blocked (should not happen — fan-out is always fire-and-continue).

Risks and Mitigations

• Risk: A misconfigured additionalTargets entry silently fails without surfacing in the job's lastRunStatus.
  • Mitigation: Failures are logged at WARN level with the [additional-delivery] prefix and the target channel/address. A follow-up could surface per-target delivery status in openclaw cron list output.
• Risk: High-frequency cron jobs with many additional targets could increase outbound message volume significantly.
  • Mitigation: This is intentional behavior; operators control the target list. Rate-limit and allowlist policies already apply via deliverOutboundPayloads.

Closes #48026 Closes #54935

Changed files

• src/auto-reply/reply/commands-session.ts (modified, +9/-10)
• src/cli/cron-cli.test.ts (modified, +216/-8)
• src/cli/cron-cli/register.cron-edit.ts (modified, +89/-0)
• src/cron/delivery.test.ts (modified, +87/-0)
• src/cron/delivery.ts (modified, +35/-1)
• src/cron/isolated-agent/delivery-dispatch.additional-targets.test.ts (added, +249/-0)
• src/cron/isolated-agent/delivery-dispatch.double-announce.test.ts (modified, +127/-0)
• src/cron/isolated-agent/delivery-dispatch.ts (modified, +110/-1)
• src/cron/isolated-agent/run.ts (modified, +38/-6)
• src/cron/normalize.test.ts (modified, +130/-0)
• src/cron/normalize.ts (modified, +31/-0)
• src/cron/service/jobs.ts (modified, +19/-1)
• src/cron/types.ts (modified, +8/-0)
• src/gateway/protocol/schema/cron.ts (modified, +10/-0)