fix(control-ui): exclude disabled cron jobs from Overview failed count#95723
Conversation
Overview surfaces counted any job whose lastRunStatus was "error" as a current failure, so an intentionally disabled job that previously failed kept inflating the top-level "failed cron" badge and attention callout. Add a shared isCronJobActiveFailure predicate that gates the error status on enabled, matching the adjacent overdue filter, and use it in both the overview card and the attention items list. Historical status stays visible in detail views via resolveCronJobLastRunStatus.
|
Codex review: needs maintainer review before merge. Reviewed June 22, 2026, 8:43 PM ET / 00:43 UTC. Summary PR surface: Source +6, Tests +40. Total +46 across 4 files. Reproducibility: yes. at source level: current main's two Overview aggregations filter only on resolved historical error status, so a disabled job retaining Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Next step before merge
Security Review detailsBest possible solution: Land this or an equivalent small UI fix after normal gates so Overview active-failure summaries ignore disabled historical errors while detail and filter surfaces preserve historical run status. Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main's two Overview aggregations filter only on resolved historical error status, so a disabled job retaining Is this the best way to solve the issue? Yes: centralizing AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 43f2b61f3b01. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +6, Tests +40. Total +46 across 4 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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
Bot
added
proof: sufficient
9fa14ff
into
openclaw:main
…aw#95723) Overview surfaces counted any job whose lastRunStatus was "error" as a current failure, so an intentionally disabled job that previously failed kept inflating the top-level "failed cron" badge and attention callout. Add a shared isCronJobActiveFailure predicate that gates the error status on enabled, matching the adjacent overdue filter, and use it in both the overview card and the attention items list. Historical status stays visible in detail views via resolveCronJobLastRunStatus.
1 participant
What Problem This Solves
The Control UI Overview counted a cron job as a current failure whenever its
state.lastRunStatus === "error", with no check on whether the job is stillactive. Both the Overview "failed cron" card hint and the attention-items list
shared this gap. As a result, a job that previously failed and was then
intentionally disabled (
enabled: false,nextRunAtMs: null) kept beingreported as an active operational problem purely because of its retained
historical error state. This makes a retired job look like a live incident and
erodes trust in Overview as a current-actionability surface. Fixes #95716.
Why This Change Was Made
Overview health is about current actionability. A disabled job cannot run
again, so a stale
lastRunStatus: "error"on it is history, not an activefailure. The adjacent "overdue jobs" computation already gates on
j.enabled;the failed-cron count was the inconsistent one. Rather than duplicate the
enabled && status === "error"check across the two surfaces (which previouslyeach inlined the predicate), this adds one shared
isCronJobActiveFailurehelper in
cron-status.tsso both surfaces stay in sync. Per-job detail viewskeep showing the historical status through
resolveCronJobLastRunStatus, whichis left unchanged.
User Impact
"N failed" badge or raise an "N cron jobs failed" attention callout.
errorstatus, so no informationis lost.
changes.
Evidence
New colocated unit test
ui/src/ui/cron-status.test.ts(3 cases) passing via therepo runner:
Before/after on a harness driving the real exported functions with the exact
job state from the issue (one disabled-after-failure job + one active failing
job):
The disabled job is dropped from the count while its historical
errorstatusis still reported for detail views; the active failing job is unchanged.
Formatting (
oxfmt --check) andoxlintclean on all four touched files.AI-assisted.