fix: report not-requested when delivery.mode=none in cron jobs (closes #44533) by Br1an67 · Pull Request #47347 · openclaw/openclaw

Br1an67 · 2026-03-15T13:28:21Z

Summary

Problem: When delivery.mode = "none" is set in a cron job, resolveDeliveryStatus() returns "not-delivered" instead of "not-requested" because it checks delivered === false before checking if delivery was even requested.
Why it matters: The "not-delivered" status implies a delivery failure, which is misleading when the user explicitly configured no delivery.
What changed: resolveDeliveryStatus() now checks resolveCronDeliveryPlan().requested first. If delivery was not requested (mode=none), it returns "not-requested" regardless of the delivered flag. Only when delivery was actually requested does it check the delivered boolean.
What did NOT change (scope boundary): No changes to resolveCronDeliveryPlan(), delivery execution, or any other status values.

Change Type

Bug fix

Scope

Linked Issue/PR

Closes [BUG] delivery.mode = "none" incorrectly reports "not-delivered" instead of "not-requested" #44533

User-visible / Behavior Changes

Cron job lastDeliveryStatus when delivery.mode = "none":

Before: "not-delivered"
After: "not-requested"

Security Impact

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

Repro + Verification

Steps

Create a cron job with delivery: { mode: "none" }
Wait for job to run
Check lastDeliveryStatus

Expected

"not-requested"

Actual (before fix)

"not-delivered"

Evidence

Failing test/log before + passing after
npx vitest run src/cron/delivery.test.ts — 11 tests passed
pnpm tsgo — no new type errors

Human Verification

Verified scenarios: pnpm tsgo + vitest tests all passing; reviewed diff matches issue description
Edge cases checked: mode=none returns not-requested; delivered=true still returns delivered; delivered=false with requested=true still returns not-delivered; delivered=undefined with requested=true returns unknown
What you did NOT verify: runtime end-to-end testing with actual cron service

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.

Compatibility / Migration

Backward compatible? Yes (status string change, no API contract break)
Config/env changes? No
Migration needed? No

Failure Recovery

How to disable/revert: revert this commit

Risks and Mitigations

None

greptile-apps · 2026-03-15T13:31:01Z

Greptile Summary

This PR fixes a bug where cron jobs configured with delivery.mode = "none" incorrectly reported a lastDeliveryStatus of "not-delivered" instead of "not-requested". The fix restructures resolveDeliveryStatus() to call resolveCronDeliveryPlan() first and return "not-requested" immediately when delivery was never requested, before checking the delivered boolean.

Correct fix: The refactoring cleanly eliminates the priority inversion — delivery intent is now checked before delivery outcome, matching the intent of the original design.
Scope overlap with mode: "webhook": resolveCronDeliveryPlan() returns requested: false for both mode: "none" and mode: "webhook" (line 86 of delivery.ts: requested: resolvedMode === "announce"). This means if a webhook-mode job ever produces delivered: true or delivered: false in its run result, that status would be silently overridden with "not-requested". Currently this is harmless because the delivery-dispatch path that sets delivered is gated by params.deliveryRequested, so webhook jobs always have delivered: undefined. The behavior is correct for the existing code, but the coupling is implicit and worth a comment.
lastDeliveryError side-effect (line 337–338): lastDeliveryError is only populated when deliveryStatus === "not-delivered". Since "not-requested" never triggers that branch, any result.error present on a mode: "none" run will not be stored in lastDeliveryError. This is intentional per the fix scope, but it means error details are not preserved even if the agent itself errored.

Confidence Score: 4/5

Safe to merge — the fix is minimal, well-scoped, and corrects a genuine status misreporting bug without touching delivery execution logic.
The change is a single-function, 4-line refactor with a clear before/after behaviour. The core fix is correct: plan.requested is checked first, so mode: "none" correctly returns "not-requested". The only reason this is not a 5 is the implicit coupling to mode: "webhook" also having requested: false — if webhook jobs ever start populating delivered, those statuses would be silently masked. That risk is theoretical today but is not guarded against in tests or comments.
No files require special attention beyond src/cron/service/timer.ts.

_{Last reviewed commit: 0b67cba}

…openclaw#44533) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

openclaw-barnacle Bot added the size: XS label Mar 15, 2026

who96 mentioned this pull request Mar 15, 2026

fix(test/whatsapp): use stale timestamp for append-skip test case #47224

Closed

fix: report not-requested when delivery.mode=none in cron jobs (closes …

0625c18

…openclaw#44533) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Br1an67 closed this Mar 15, 2026

Br1an67 force-pushed the fix/44533 branch from 0b67cba to 0625c18 Compare March 15, 2026 21:47

Br1an67 requested review from a team and steipete as code owners March 15, 2026 21:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: report not-requested when delivery.mode=none in cron jobs (closes #44533)#47347

fix: report not-requested when delivery.mode=none in cron jobs (closes #44533)#47347
Br1an67 wants to merge 1 commit into
openclaw:mainfrom
Br1an67:fix/44533

Br1an67 commented Mar 15, 2026

Uh oh!

greptile-apps Bot commented Mar 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant