Summary

isStaggeredCronRunAtMs probes the cron library at runAtMs + 1 to decide whether a persisted nextRunAtMs is a real schedule slot. Croner-style second-granular schedules normalize that 1ms probe back to the candidate's second, so previousRuns(1, runAtMs + 1) returns the slot before the candidate instead of the candidate itself. shouldRepairFutureCronNextRunAtMs then classifies valid exact-second slots that fall two-plus intervals into the future as stale and rebases them.

Probe at runAtMs + 1_000 instead so the previous-run lookup lands past the candidate second. This matches the +1_000 cursor step used elsewhere in the same file (computeStaggeredCronNextRunAtMs line 109, computeStaggeredCronPreviousRunAtMs line 137).

The bug only surfaces when nextRunAtMs is two-plus intervals past the natural next slot, because closer cases are already saved by the nextRun === naturalNext and followingNaturalNext guards in shouldRepairFutureCronNextRunAtMs. The new regression test pins the path that the existing guards miss.

Fixes #81691

Real behavior proof

• Behavior addressed: A persisted exact-second cron nextRunAtMs falling two-plus schedule intervals into the future is misclassified as not-a-slot by isStaggeredCronRunAtMs, then rebased by shouldRepairFutureCronNextRunAtMs despite being a valid scheduled slot. The user-visible symptom is an unexpected reschedule of a future cron firing for any cron job whose persisted nextRunAtMs sits more than one schedule interval ahead.

• Real environment tested: Local OpenClaw checkout on macOS 14 (arm64), Node 22.20.0, pnpm 11.1.0, croner resolved from the repo's pnpm-lock.yaml. No live gateway run was required because the misclassification reproduces directly against the same croner library the cron service uses at runtime; the regression test exercises the actual recomputeNextRunsForMaintenance code path on a real CronJob value, not a mock.

• Exact steps or command run after this patch:

  1. Reproduced the underlying croner quirk against the issue's literal inputs by running a short node script from the repo root with the in-tree croner resolution:

     node -e "import('croner').then(({Cron}) => { const c = new Cron('0 9 * * *', { timezone: 'Pacific/Honolulu' }); const slot = new Date('2026-05-08T19:00:00.000Z'); console.log('+1ms ->', c.previousRuns(1, new Date(slot.getTime() + 1))[0].toISOString()); console.log('+1s  ->', c.previousRuns(1, new Date(slot.getTime() + 1_000))[0].toISOString()); })"
     

  2. Ran the new regression test in isolation:

     node scripts/run-vitest.mjs src/cron/service.jobs.test.ts
     

  3. Ran the full cron lane to confirm no neighbours regress:

     node scripts/run-vitest.mjs src/cron/
     

  4. Lane-scoped lint/format/types:

     pnpm exec oxlint --config .oxlintrc.json src/cron/service/jobs.ts src/cron/service.jobs.test.ts
     pnpm exec oxfmt --check src/cron/service/jobs.ts src/cron/service.jobs.test.ts
     pnpm tsgo:core
     

  5. RED→GREEN proof: stashed only src/cron/service/jobs.ts, re-ran the focused test (1 failure), restored, re-ran (56 passed).

• Evidence after fix:

  • Live croner probe (step 1) on this checkout shows the issue's reported behavior and that the new probe lands on the slot:

    +1ms -> 2026-05-07T19:00:00.000Z   ← pre-fix probe returns yesterday's slot
    +1s  -> 2026-05-08T19:00:00.000Z   ← post-fix probe returns the actual slot
    

  • Vitest output for the focused regression test (step 2):

     RUN  v4.1.6 /Users/yashwantkotipalli/Projects/openclaw
    
     Test Files  1 passed (1)
          Tests  56 passed (56)
       Start at  00:23:34
       Duration  177ms
    

  • Vitest output for the full cron lane (step 3):

     Test Files  91 passed (91)
          Tests  837 passed (837)
       Start at  00:24:32
       Duration  30.50s
    

  • RED proof — with the fix stashed:

     × preserves exact-second cron slots that fall multiple intervals into the future (#81691)
    AssertionError: expected true to be false
     Test Files  1 failed (1)
          Tests  1 failed | 55 passed (56)
    

• Observed result after fix: The persisted nextRunAtMs = 2026-05-08T19:00:00.000Z on a "0 9 * * *" Pacific/Honolulu cron is now classified as a real schedule slot, shouldRepairFutureCronNextRunAtMs returns false, recomputeNextRunsForMaintenance returns false, and the timestamp is left intact instead of being rebased to the next natural slot. All 837 cron tests stay green and the targeted oxlint, oxfmt, and pnpm tsgo:core lanes are clean.

• What was not tested:

  • I did not run pnpm check:changed end-to-end because the tsgo:test:src lane surfaces 9 pre-existing errors on origin/main for unrelated optional native deps (sharp, esbuild, baileys) that my checkout cannot install. The same 9 errors are present with my patch stashed; the patch introduces zero new diagnostics. The targeted pnpm tsgo:core lane passes clean.
  • I did not exercise this through a live cron gateway. The fix is a pure-arithmetic adjustment of a single private helper covered by the new regression test plus the existing 56-test recomputeNextRuns suite.

CI status note

The non-Real behavior proof red checks on this PR are all already red on the latest origin/main head and are unrelated to the cron change:

• checks-node-core-runtime-media-ui is failing on src/wizard/setup.official-plugins.test.ts:107 (installs selected optional official plugins through the shared onboarding installer). The same shard fails on origin/main run 25847797276 at the same line; locally the file passes 6/6.
• checks-node-core-support-boundary is a cascade from build-artifacts' test/release-check.test.ts failures at lines 505 and 538 (collectMissingPackPaths). Same two failures present on origin/main run 25848244306.
• checks-node-core is the meta-aggregator for those two shards and turns red whenever either does.

The cron change does not touch wizard, release-check, or any shared boundary surface; the regression test is colocated with the file under change.

Notes

• AI-assisted: drafted with Claude. Verified the cron-library probe behavior locally against the issue's exact inputs before opening, then again under stash/pop to prove RED→GREEN.
• No changelog edit (per contributor guidance; maintainers/ClawSweeper handle the entry on landing).