Summary

Describe the problem and fix in 2–5 bullets:

• Problem: Startup catch-up executions in runMissedJobs bypassed cron timeout handling.
• Why it matters: A stuck startup catch-up run could block catch-up completion indefinitely.
• What changed: Startup catch-up now uses executeJobCoreWithTimeout(...), and a regression test verifies timeout/abort behavior.
• What did NOT change (scope boundary): No schedule semantics, retry backoff policy, or delivery behavior changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• 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 #
• Related #

User-visible / Behavior Changes

• Cron startup catch-up isolated runs now honor timeoutSeconds the same way timer/manual runs do.

Security Impact (required)

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

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22+, Vitest
• Model/provider: N/A (test harness)
• Integration/channel (if any): N/A
• Relevant config (redacted): default test cron config

Steps

1. Add an isolated one-shot cron job due at startup with timeoutSeconds: 0.01.
2. Execute startup catch-up path (runMissedJobs).
3. Assert the abort signal is observed and job ends in timeout error state.

Expected

• Startup catch-up run times out and records error state.

Actual

• Verified: run is aborted and timeout error is recorded.

Evidence

Attach at least one:

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

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Ran pnpm -s vitest run src/cron/service.issue-regressions.test.ts in /Users/thoffman/openclaw-wt-cron-1.
• Edge cases checked: Startup catch-up timeout-specific regression added and passing.
• What you did not verify: Full-suite cron tests and multi-channel live integrations.

Compatibility / Migration

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

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this commit/PR.
• Files/config to restore: src/cron/service/timer.ts, src/cron/service.issue-regressions.test.ts.
• Known bad symptoms reviewers should watch for: Startup catch-up runs not timing out.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk:
  • Mitigation: Regression coverage ensures startup catch-up follows existing timeout path.

Greptile Summary

This PR fixes a bug where startup catch-up executions in runMissedJobs bypassed cron timeout handling. The fix ensures that startup catch-up runs now use executeJobCoreWithTimeout(...) instead of executeJobCore(...), applying the same timeout behavior as timer and manual runs. The change is minimal and focused, with a comprehensive regression test that verifies the timeout abort signal is properly observed during startup catch-up.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The change is a simple one-line fix replacing executeJobCore with executeJobCoreWithTimeout in the startup catch-up path. The implementation is already proven in the timer and manual execution paths. The regression test comprehensively validates the timeout behavior with real abort signal verification. No breaking changes to existing behavior.
• No files require special attention

_{Last reviewed commit: 5ca52cb}