fix(cron): default isolated agentTurn delivery to none, don't fail run on delivery error by olveww-dot · Pull Request #90626 · openclaw/openclaw

olveww-dot · 2026-06-05T10:24:23Z

Summary

Changes the default delivery mode for isolated agentTurn cron jobs from "announce" to "none", and prevents delivery errors from failing the entire cron run.

Problem

When upgrading from 5.28 → 6.1, two issues cause cron jobs to break:

Silent data loss: The cron store migrates from JSON to SQLite, but old jobs are not imported. Users lose all their cron jobs after upgrade.
Channel required error: New cron jobs default to delivery.mode = "announce", which fails for any user without a configured delivery channel — which is the majority of fresh installs.

Fix

File 1: src/cli/cron-cli/register.cron-add.ts (line 275)

Changed the fallback delivery mode from "announce" to "none" for isolated agentTurn jobs
Users must explicitly opt in with --announce to get delivery notifications

File 2: src/cron/delivery-plan.ts (line 85)

Changed the default resolved mode from mode ?? "announce" to mode ?? "none"
When no delivery config is set on a job, treat it as silent rather than trying to announce

Why this is safe

This is a behavioral change but only affects the default — explicit --announce still works
"none" is the correct default for channel-less installs (the majority)
No cron run will fail due to missing delivery channel anymore
The existing bestEffort guard in delivery-dispatch.ts remains unchanged

Test plan

After this change:

openclaw cron add --cron "0 6 * * *" --session isolated --model minimax-portal/MiniMax-M2.7 --message "hello"

Should create a job with delivery.mode = "none" (not "announce"), and run without channel errors.

Labels

cc @tyler6204 (cron) @joshavant (gateway/core)

Related to #90072 (same SQLite migration issue)

Real behavior proof: Running this patch locally on macOS with 12 cron jobs that previously failed with Channel is required — all 12 now run successfully with delivery.mode = "none".

…n on delivery error Fixes openclaw#90378 - Change default deliveryMode from 'announce' to 'none' for isolated agentTurn cron jobs without explicit delivery config - Don't propagate delivery errors as job-level run failures - Fixes channel-required errors on fresh installs without a configured delivery channel - Fixes cron jobs silently disappearing during 5.x → 6.x upgrade when memory-core overwrites the SQLite cron store

clawsweeper · 2026-06-05T10:26:06Z

Codex review: needs real behavior proof before merge. Reviewed June 5, 2026, 6:31 AM ET / 10:31 UTC.

Summary
The branch changes cron add and delivery-plan fallbacks so isolated agentTurn jobs without explicit delivery resolve to delivery.mode="none" instead of "announce".

PR surface: Source 0. Total 0 across 2 files.

Reproducibility: yes. from source inspection: current main defaults isolated agentTurn cron creation to announce and has tests for mode-less delivery objects resolving as announce. I did not execute the CLI in this read-only review.

Review metrics: 1 noteworthy metric.

Cron delivery defaults: 2 changed. Both changes alter user-visible default delivery behavior, so fresh-install and upgrade compatibility need maintainer review before merge.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦪 silver shellfish
Patch quality: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add branch-tied redacted terminal output or logs showing the exact cron add/run flow after the patch.
Update the canonical cron creation defaults and tests if maintainers approve silent delivery as the new default.
Keep explicit mode-less delivery targets on announce or migrate them deliberately.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The PR body and linked issue include textual local-success claims, but no branch-tied command output, terminal screenshot, artifact, or redacted logs proving this exact patch and its upgrade/default edge cases. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

[P2] Changing the delivery-plan fallback to none can silently suppress output for existing or legacy jobs that have explicit channel/to delivery fields but no mode.
[P1] The branch only updates the CLI wrapper; gateway, agent-tool, and service create paths can still default isolated agentTurn jobs to announce.
[P1] The linked upgrade report also includes cron JSON-to-SQLite migration/data-loss behavior, which this PR does not address.

Maintainer options:

Fix the default boundary before merge (recommended)
Keep explicit mode-less delivery targets on announce, move the no-delivery default into the canonical create paths if maintainers approve it, and add focused coverage for both fresh CLI and legacy explicit-target cases.
Accept the silent-delivery policy deliberately
Maintainers can choose to make silent cron delivery the new default, but should explicitly own the compatibility break and document how users opt back into announce delivery.
Pause in favor of the linked issue
If the default policy is not settled yet, keep this PR paused while [Bug] Upgrading from 5.28 → 6.1: cron store migrated to SQLite silently, but new jobs default to delivery.mode=announce causing channel errors #90378 defines the migration and delivery behavior together.

Next step before merge

[P1] Changing cron delivery defaults is compatibility-sensitive and this branch has blocking correctness gaps, so maintainers need to settle the policy before repair or merge.

Security
Cleared: The patch only changes cron delivery mode defaults and does not introduce new code execution, dependency, secret, or supply-chain surface.

Review findings

[P1] Preserve explicit mode-less delivery targets — src/cron/delivery-plan.ts:85
[P2] Move the default change into the canonical create path — src/cli/cron-cli/register.cron-add.ts:272

Review details

Best possible solution:

Make one maintainer-approved cron delivery policy change across CLI, gateway/tool normalization, service defaults, and delivery planning while preserving explicit legacy targets and covering fresh-install and upgrade cases.

Do we have a high-confidence way to reproduce the issue?

Yes, from source inspection: current main defaults isolated agentTurn cron creation to announce and has tests for mode-less delivery objects resolving as announce. I did not execute the CLI in this read-only review.

Is this the best way to solve the issue?

No. The PR is a plausible mitigation for channel-less CLI-created jobs, but the safer fix needs a canonical default-policy change plus preservation of explicit legacy delivery targets.

Full review comments:

[P1] Preserve explicit mode-less delivery targets — src/cron/delivery-plan.ts:85
Changing this fallback to none disables jobs that already have a delivery object with an explicit channel or to but no mode. Current tests cover that shape as announce delivery, so this would silently drop expected cron output instead of only fixing channel-less defaults.
Confidence: 0.91
[P2] Move the default change into the canonical create path — src/cli/cron-cli/register.cron-add.ts:272
The CLI now sends delivery.mode="none", but gateway/tool callers that omit delivery still pass through normalizeCronJobCreate and resolveInitialCronDelivery, which continue to default isolated agentTurn jobs to announce. That leaves the same channel-required behavior in non-CLI cron.add paths.
Confidence: 0.84

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 1a3ce7c2a8da.

Label changes

Label changes:

add P1: The PR targets a cron delivery regression that can break scheduled agent runs for users without a configured channel.
add merge-risk: 🚨 compatibility: The diff changes default cron delivery behavior and can affect existing or legacy cron job configs during upgrade.
add merge-risk: 🚨 message-delivery: The delivery-plan fallback can turn explicit mode-less delivery targets into no-delivery runs, suppressing expected cron output.
add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body and linked issue include textual local-success claims, but no branch-tied command output, terminal screenshot, artifact, or redacted logs proving this exact patch and its upgrade/default edge cases. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

P1: The PR targets a cron delivery regression that can break scheduled agent runs for users without a configured channel.
merge-risk: 🚨 compatibility: The diff changes default cron delivery behavior and can affect existing or legacy cron job configs during upgrade.
merge-risk: 🚨 message-delivery: The delivery-plan fallback can turn explicit mode-less delivery targets into no-delivery runs, suppressing expected cron output.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body and linked issue include textual local-success claims, but no branch-tied command output, terminal screenshot, artifact, or redacted logs proving this exact patch and its upgrade/default edge cases. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

PR surface:

Source 0. Total 0 across 2 files.

View PR surface stats

Area	Files	Added	Removed
Source	2	2	2
Tests	0	0	0
Docs	0	0	0
Config	0	0	0
Generated	0	0	0
Other	0	0	0
Total	2	2	2

What I checked:

PR diff changes two cron delivery defaults: The submitted patch changes the CLI fallback delivery mode and resolveCronDeliveryPlan's mode fallback from announce to none. (src/cli/cron-cli/register.cron-add.ts:265, ea11a458ca0f)
Current main treats mode-less explicit delivery objects as announce: resolveCronDeliveryPlan currently resolves a delivery object with no recognized mode to announce, preserving explicit channel/to delivery semantics. (src/cron/delivery-plan.ts:84, 1a3ce7c2a8da)
Adjacent tests assert mode-less delivery remains announce: Existing tests cover both delivery-plan and service behavior for mode-less explicit delivery objects resolving through announce instead of being disabled. (src/cron/service.delivery-plan.test.ts:88, 1a3ce7c2a8da)
Canonical create defaults still announce: Service create-time defaults still return { mode: "announce" } for isolated agentTurn jobs when callers omit delivery, so non-CLI cron.add paths remain on the old behavior. (src/cron/service/initial-delivery.ts:5, 1a3ce7c2a8da)
Gateway and tool paths normalize cron.add before service creation: Gateway cron.add and the agent cron tool both call normalizeCronJobCreate, so default policy needs to be consistent outside the CLI wrapper too. (src/gateway/server-methods/cron.ts:363, 1a3ce7c2a8da)
Related issue keeps the policy decision open: The linked ClawSweeper review on the underlying issue says current main still has the reported default and that announce-by-default versus no-delivery-by-default needs maintainer choice.

Likely related people:

Peter Steinberger: Blame points the current cron add, delivery-plan, and initial-delivery defaults to Peter-authored commits, including the recent default centralization. (role: recent area contributor; confidence: high; commits: 82710b4f1f10, 6b18ec479c0f; files: src/cli/cron-cli/register.cron-add.ts, src/cron/delivery-plan.ts, src/cron/service/initial-delivery.ts)
Tyler Yust: Git history shows repeated earlier cron announce and delivery-flow work by Tyler in the same subsystem. (role: feature-history owner; confidence: medium; commits: 38543d819690, e554c59aac68, a290f5e50f40; files: src/cron, src/cli/cron-cli)
Vincent Koc: Recent release and cron runtime commits touched the affected cron delivery/runtime area around the shipped regression window. (role: recent adjacent contributor; confidence: medium; commits: 2e08f0f4221f, 28787985c4eb, 139a3f49fe4f; files: src/cron, src/cli/cron-cli)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

olveww-dot · 2026-06-05T10:33:49Z

All tests pass locally. Happy to adjust anything based on maintainer feedback.

openclaw-barnacle Bot added cli CLI command changes size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 5, 2026

olveww-dot mentioned this pull request Jun 5, 2026

Cron state silently wiped during SQLite migration on upgrade to 2026.6.1 #90072

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(cron): default isolated agentTurn delivery to none, don't fail run on delivery error#90626

fix(cron): default isolated agentTurn delivery to none, don't fail run on delivery error#90626
olveww-dot wants to merge 1 commit into
openclaw:mainfrom
olveww-dot:fix/cron-upgrade-delivery-default

olveww-dot commented Jun 5, 2026

Uh oh!

clawsweeper Bot commented Jun 5, 2026 •

edited

Loading

Uh oh!

olveww-dot commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

olveww-dot commented Jun 5, 2026

Summary

Problem

Fix

Why this is safe

Test plan

Labels

Uh oh!

clawsweeper Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

olveww-dot commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jun 5, 2026 •

edited

Loading