Summary

• Problem: recurring main-session cron jobs with --wake now stay inside the cron run while runHeartbeatOnce keeps returning requests-in-flight, which inflates lastDurationMs and lets schedule drift accumulate.
• Why it matters: short recurring jobs like */3 * * * * can appear to run for minutes and miss later slots even with --exact.
• What changed: recurring main-session jobs now fall back to requestHeartbeatNow() immediately after the first busy runHeartbeatOnce result instead of busy-waiting in the cron lane.
• What did NOT change (scope boundary): one-shot --at jobs still keep the existing synchronous wait-for-heartbeat behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Cron jobs are not executing as scheduled. #58833
• Related [Bug]: Cron jobs are not executing as scheduled. #58833
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: executeMainSessionCronJob() retried runHeartbeatOnce() for up to the busy-wait window even for recurring jobs, so the cron run duration included main-lane contention instead of just cron scheduling work.
• Missing detection / guardrail: there was coverage for one-shot wakeMode=now behavior, but no regression test for recurring main-session jobs under requests-in-flight pressure.
• Prior context (git blame, prior PR, issue, or refactor if known): Unknown.
• Why this regressed now: under heavier gateway load, recurring cron jobs can hit the busy main lane path repeatedly, which magnifies duration inflation and drift.
• If unknown, what was ruled out: the per-job cron stagger path and post-run duration math were not the primary cause here.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cron/service.issue-regressions.test.ts
• Scenario the test should lock in: a recurring main-session cron job with wakeMode="now" and runHeartbeatOnce() returning requests-in-flight should request a queued heartbeat immediately and complete with a short recorded duration.
• Why this is the smallest reliable guardrail: it exercises the exact scheduler path without requiring broader gateway/runtime setup.
• Existing test that already covers this (if any): src/cron/service.runs-one-shot-main-job-disables-it.test.ts covers one-shot wakeMode now behavior, but not recurring jobs.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Recurring main-session cron jobs using --wake now no longer sit in a long busy-wait loop when the main lane is already busy. Their cron run finishes quickly after queueing the immediate heartbeat, which keeps lastDurationMs closer to scheduler overhead and reduces drift from blocked cron slots.

Diagram (if applicable)

Before:
[recurring cron due] -> [enqueue system event] -> [busy runHeartbeatOnce loop] -> [minutes counted as cron duration] -> [later slots drift]

After:
[recurring cron due] -> [enqueue system event] -> [first busy runHeartbeatOnce] -> [requestHeartbeatNow] -> [cron run completes quickly]

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local test runner
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): recurring main-session cron job with wakeMode=now

Steps

1. Create a recurring main-session cron job with wakeMode=now.
2. Make runHeartbeatOnce() return { status: "skipped", reason: "requests-in-flight" }.
3. Execute the job and inspect the recorded result.

Expected

• The cron job should enqueue the event, request an immediate heartbeat, and finish quickly.

Actual

• Before this change, the cron job stayed in the busy-wait retry loop and recorded an inflated duration.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: ran pnpm test -- src/cron/service.issue-regressions.test.ts -t "#58833|busy-recurring-main|main lane is busy" and pnpm test -- src/cron/service.runs-one-shot-main-job-disables-it.test.ts -t "wakeMode now".
• Edge cases checked: confirmed the existing one-shot wakeMode now tests still pass, so the synchronous one-shot behavior remains intact.
• What you did not verify: full repo-wide pnpm check is currently failing due to unrelated existing tsgo errors outside the cron surface.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: recurring main-session jobs now stop waiting sooner when the main lane is busy, so their cron run status reflects successful queueing rather than completed main-lane processing.
  • Mitigation: the change is limited to recurring jobs; one-shot jobs keep the existing wait-for-heartbeat behavior, and the new regression test locks in the intended fallback path.