PR #61431: test(cron): lock explicit isolated delivery.channel routing

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

Description (problem / solution / changelog)

Summary

• Problem: #61414 reports isolated cron agent turns ignoring an explicit delivery.channel and falling back to last.
• Why it matters: if that behavior regresses, cron output can land on the wrong surface.
• What changed: add regression coverage for the exact isolated agentTurn + explicit delivery.channel case in both the delivery planner and job creation path.
• What did NOT change (scope boundary): no runtime delivery logic changed in this PR; current main already preserves explicit channels in resolveCronDeliveryPlan().

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 #
• Related #61414
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the user-visible report in #61414 describes older release behavior, but current main already preserves explicit delivery.channel when job.delivery is present. The missing piece on main was regression coverage for that exact route.
• Missing detection / guardrail: there was no targeted test proving isolated agentTurn jobs keep an explicit channel like webchat instead of falling back to last.
• Contributing context (if known): the issue cited compiled 2026.4.1 output; current source under src/cron/delivery-plan.ts already takes the explicit-delivery branch before the implicit isolated fallback.

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/delivery.test.ts
  • src/cron/service.jobs.test.ts
• Scenario the test should lock in: isolated agentTurn jobs with delivery: { mode: "announce", channel: "webchat" } keep webchat through both job creation and delivery-plan resolution.
• Why this is the smallest reliable guardrail: the reported behavior is fully determined by the cron job creation + delivery-planning helpers, so focused tests on those helpers catch the regression without a larger end-to-end harness.
• Existing test that already covers this (if any): none specific to explicit delivery.channel on isolated jobs.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

None on current main; this locks existing behavior so it does not regress.

Diagram (if applicable)

Before:
[isolated cron agentTurn + delivery.channel=webchat] -> [behavior depended on helper correctness]

After:
[isolated cron agentTurn + delivery.channel=webchat] -> [targeted tests assert webchat survives] -> [future regressions fail fast]

Security Impact (required)

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

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / Vitest
• Model/provider: N/A
• Integration/channel (if any): cron delivery planning
• Relevant config (redacted): isolated agentTurn with delivery.channel: "webchat"

Steps

1. Create an isolated cron agentTurn with delivery: { mode: "announce", channel: "webchat" }.
2. Resolve the delivery plan and create the job.
3. Assert both helpers preserve webchat instead of falling back to last.

Expected

• Explicit delivery.channel stays webchat.

Actual

• Current main already behaves that way; these tests now lock it in.

Evidence

Attach at least one:

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

Human Verification (required)

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

• Verified scenarios:
  • resolveCronDeliveryPlan() preserves delivery.channel="webchat" for isolated agentTurn jobs.
  • createJob() preserves explicit delivery config instead of collapsing it to implicit announce defaults.
• Edge cases checked:
  • implicit isolated delivery still defaults to last
  • explicit delivery still works when mode is omitted or changed elsewhere in existing tests
• What you did not verify:
  • I did not run a full end-to-end gateway cron delivery scenario because the helper-level tests fully cover the reported routing decision path.

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)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: this is test-only, so if the real issue was in a release-only compiled artifact or another downstream path, this PR will not address that separately.
  • Mitigation: the PR body is explicit about the current main behavior and scopes the change to regression coverage for the planner/create path implicated by #61414.

Changed files

• src/cron/delivery.test.ts (modified, +12/-0)
• src/cron/service.jobs.test.ts (modified, +5/-2)