fix(cron): persist settled failure-alert delivery outcome to job state …

[warren-run-bot]

Summary

fix(cron): persist settled failure-alert delivery outcome to job state and run history

Run

• Warren run: run_ywv0dx8tb3sc
• Agent: pi
• Cost: $2.43 (92.2k in / 42.0k out / 8.2M cache-r)

Commits (4)

• 6487a65 fix(cron): persist settled failure-alert delivery outcome to job state and run history
• 4aeb1d4 test(cron): expect settled failure-alert delivery outcomes
• 3fd6efe test(cron): cover settled failure-alert delivery write-back (success, failure, fallback)
• ed89f75 test(cron): expect settled delivery outcomes in cron delivery e2e coverage

Files changed

src/cron/cron-delivery-outcomes.e2e.test.ts        |  38 ++++--
 src/cron/service.persists-delivered-status.test.ts |   8 +-
 .../service/failure-alerts.persistence.test.ts     | 133 ++++++++++++++++++++-
 src/cron/service/failure-alerts.ts                 |  60 ++++++++++
 src/cron/service/task-runs.ts                      |  48 ++++++++
 5 files changed, 271 insertions(+), 16 deletions(-)

Prompt

Show prompt

Work on OpenClaw GitHub issue #131847: cron failure-alert delivery status is never written back after the send settles. In src/cron/service/failure-alerts.ts, markFailureNotificationRequested() sets the job's lastFailureNotificationDeliveryStatus to "unknown" before the async send starts, and transportFailureAlert() invokes sendCronFailureAlert(...) fire-and-forget via void ....catch(...): the .catch() path logs a warning and triggers a fallback re-queue, but neither the success path nor the catch path ever writes the real outcome back, so lastFailureNotificationDeliveryStatus / lastFailureNotificationDelivered / lastFailureNotificationDeliveryError on the job, and the persisted failureNotificationDelivery record on the run history, permanently read status "unknown". Fix: when the failure-alert send settles, persist the true outcome to both the job state and the run-history record — on success, delivered: true with the appropriate status; on failure, delivered: false with a real status and the error value (and record the outcome when the fallback re-queue path fires too) — so an operator can audit after the fact whether alerting worked. The fields already exist and are read in failureNotificationDeliveryFromJobState(); write real outcomes into them rather than introducing new fields, stores, or config surface. Preserve existing field names and shapes. Add or extend focused tests proving the success write-back, the failure write-back with the error captured, and the fallback-path outcome. COMMIT DISCIPLINE (critical): commit your work with git as soon as each coherent change compiles, BEFORE running any validation, and keep committing incrementally — never leave completed work uncommitted while a long command runs. VALIDATION DISCIPLINE (critical): validation must be scoped and bounded. Run only the focused test files for the code you changed (e.g. a single vitest/test path), never repo-wide commands — no pnpm build, no pnpm check, no pnpm check:changed, no full pnpm test, no repo-wide format. Give every shell command an explicit timeout of at most 600 seconds; if a scoped test cannot finish in that budget, record that in your summary instead of waiting. Follow the repository's contribution rules strictly: no refactor-only changes, no unrelated edits, and do not touch CHANGELOG.md, .github/workflows/, .github/CODEOWNERS, SECURITY.md, package.json, or any lockfile. In your final summary, record exactly which commands you ran and their results as evidence. PROVEN APPROACH — a previous run designed and validated this fix, passing 37 focused tests, but its work was lost to an infrastructure failure before push; reuse this approach to move fast: in src/cron/service/failure-alerts.ts, record the settled outcome on the send promise — on success set delivered: true with status "delivered"; on rejection set delivered: false with status "not-delivered" and capture the error; make the fallback re-queue path record its outcome as well; persist to both the job state and the run-history record (src/cron/service/task-runs.ts). Also update existing tests that assert the permanent "unknown" delivery status (e.g. src/cron/cron-delivery-outcomes.e2e.test.ts) to expect the settled outcome. BUDGET DISCIPLINE (critical): this run has a hard cost cap and a previous attempt was cancelled at its cap during final verification. Be economical: minimal exploration, follow the proven approach above, and THE MOMENT your focused tests pass, commit, write your final summary, and end the session. No extra verification passes, no repo-wide greps, no polish after green tests.

--- BEGIN AGENT GUIDANCE (repository policy agentGuidance v1) ---
The repository policy binds the following contribution norms. They are binding for this run:
1. Produce the smallest possible diff that resolves the issue; scope changes to what the reviewed issue actually requires.
2. Never introduce or reserve new public configuration or API surface without explicit maintainer direction; if the fix seems to need one, state the need as a question instead.
3. Never add fail-closed validation over input that was previously accepted and valid; tightening input rules is a behavior change that belongs to the maintainers.
4. Before summarizing, search the codebase for existing mechanisms that already address the same failure and cite them in the final summary; do not miss an existing fallback.
5. State unprovable claims as known gaps rather than omitting them; silent omissions are harder for review to catch than declared uncertainty.
--- END AGENT GUIDANCE ---

---

🤖 Opened by warren run run_ywv0dx8tb3sc