Summary

• Problem: Startup catch-up cron runs never set the in-process active marker (markCronJobActive), so while a catch-up job is running isCronJobActive(jobId) returns false. The task-registry reconcile uses this marker to detect lost tasks — any catch-up run exceeding TASK_RECONCILE_GRACE_MS (5 min) is misclassified as lost, emitting a spurious Background task lost system message.
• Root Cause: runStartupCatchupCandidate in src/cron/service/timer.ts calls tryCreateCronTaskRun and emits action:"started" but never calls markCronJobActive, unlike the sibling tick paths (runDueJob at line 888, executeJob at line 1672) which both mark active. The completion path still calls clearCronJobActive via applyOutcomeToStoredJob, creating an asymmetric clear-without-mark.
• Fix: Add markCronJobActive(candidate.job.id) in runStartupCatchupCandidate before tryCreateCronTaskRun, matching the pattern used by runDueJob.
• What changed:
  • src/cron/service/timer.ts — added markCronJobActive(candidate.job.id) in runStartupCatchupCandidate
• What did NOT change (scope boundary):
  • The completion path (applyOutcomeToStoredJob → clearCronJobActive) — it already works correctly for all paths
  • The HEARTBEAT_SKIP_CRON_IN_PROGRESS guard — engaging it for catch-up is a separate concern

Reproduction

1. Configure a command-kind cron job (non-agentTurn)
2. Restart the gateway so the missed job is replayed as startup catch-up
3. The catch-up run takes longer than 5 minutes (TASK_RECONCILE_GRACE_MS)
4. Before this PR: The task registry reconcile marks the job lost and emits Background task lost while the job is still actively running
5. After this PR: isCronJobActive(jobId) returns true during the catch-up run, preventing false lost classification

Real behavior proof

Behavior or issue addressed (91695): Startup catch-up cron runs now call markCronJobActive so the task registry reconcile correctly recognizes them as in-progress rather than classifying long-running catch-up jobs as lost.

Real environment tested: Linux, Node 22 — Vitest with the cron vitest config against restart-catchup, timer, and jobs test suites

Exact steps or command run after this patch: node scripts/run-vitest.mjs src/cron/service.restart-catchup.test.ts src/cron/service/timer.test.ts src/cron/service/timer.regression.test.ts src/cron/service.jobs.test.ts src/cron/active-jobs-manual-run.test.ts src/cron/service.failure-alert.test.ts

Evidence after fix:

Test Files  6 passed (6)
     Tests  145 passed (145)
  Start at  21:17:29
  Duration  5.71s

Observed result after fix: The runStartupCatchupCandidate function now calls markCronJobActive(candidate.job.id) before dispatching the job, matching the symmetric mark-then-clear pattern already used by runDueJob and executeJob. The restart-catchup test suite, timer regression tests, and active-jobs tests all continue to pass.

What was not tested: A live gateway restart with a long-running catch-up cron job that exceeds the 5-minute reconcile grace period. The unit tests exercise the cron service state machine but not the full task-registry reconcile cycle with real time.

Repro confirmation: Before this patch, runStartupCatchupCandidate has no markCronJobActive call between tryCreateCronTaskRun and executeJobCoreWithTimeout, while the sibling runDueJob path (line 888) calls it. After this patch, both paths call markCronJobActive before dispatching.

Risk / Mitigation

• Risk: Marking the job active for catch-up could prevent the heartbeat skip guard (HEARTBEAT_SKIP_CRON_IN_PROGRESS) from engaging during startup
  Mitigation: The heartbeat skip guard is a separate concern that was already not engaged for catch-up runs. This PR only fixes the reconcile false-positive; engaging the heartbeat guard for catch-up is a follow-up.
• Risk: If runStartupCatchupCandidate throws after markCronJobActive but before clearCronJobActive, the marker could leak
  Mitigation: The executeJobCoreWithTimeout call is wrapped in try/catch, and applyOutcomeToStoredJob (which calls clearCronJobActive) runs in the finally block via the outcome processing path.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• cron / scheduling

Regression Test Plan

• node scripts/run-vitest.mjs src/cron/service.restart-catchup.test.ts
• node scripts/run-vitest.mjs src/cron/service/timer.test.ts
• node scripts/run-vitest.mjs src/cron/service/timer.regression.test.ts
• node scripts/run-vitest.mjs src/cron/service.jobs.test.ts

Review Findings Addressed

N/A (initial submission)

Linked Issue/PR

Fixes #91695