Fix large-negative setTimeout delay causing allowPast jobs to never fire in Deno

[Copilot]

When scheduling a fire-once job with allowPast: true and a far-past date, msToNext() returns a large negative value. Deno coerces this to an unsigned 32-bit integer before passing it to the OS timer, turning e.g. -197331393963 ms into ~237101653 ms (~2.7 days), so the job silently never fires.

Change

• src/croner.ts — schedule(): Clamp waitMs to 0 when negative, after the existing maxDelay cap. When the job is paused, use a 1 s backoff instead of 0 to prevent a tight setTimeout(0) → _checkTrigger → schedule() rescheduling loop.

if (waitMs > maxDelay) waitMs = maxDelay;
if (waitMs < 0) waitMs = this._states.paused ? 1000 : 0;  // ← new

• test/croner.test.ts: Added a regression test that creates a fire-once job with allowPast: true, paused: true, and a far-past date, then calls resume() and asserts it fires within a bounded time.

_checkTrigger still evaluates now >= target before firing, so clamping to 0 means "check immediately" — not "fire unconditionally". Node.js and Bun were unaffected because they perform this clamping natively; Deno does not.

[Copilot]

Pull request overview

This PR fixes a cross-runtime scheduling bug where very large negative setTimeout delays (e.g., fire-once jobs in the far past with allowPast: true) can be coerced into large positive delays in Deno, preventing the job from firing.

Changes:

• Clamp negative waitMs values to 0 in Cron.schedule() after applying the existing maxDelay cap.
• Add an explanatory comment documenting the Deno-specific overflow/coercion behavior and its impact.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Clamping negative waitMs to 0 can create a tight rescheduling loop when the job is paused and the target time is already in the past (e.g. paused: true + allowPast: true + far-past once date). In that case _checkTrigger never fires because paused, but schedule() keeps computing a negative delay and scheduling setTimeout(..., 0) repeatedly, which can cause high CPU usage. Consider adding a small backoff when paused/overdue (or changing pause/resume behavior to avoid rescheduling while paused).

[Hexagon]

@copilot apply changes based on the comments in this thread . Keep it safe. Minimal changes.

[Copilot]

@copilot apply changes based on the comments in this thread . Keep it safe. Minimal changes.

Applied in 5e06563. When waitMs < 0 and the job is paused, we now use a 1s backoff instead of 0 to prevent the tight setTimeout(0) → _checkTrigger → schedule() loop. When not paused, still clamps to 0 so the job fires immediately. All 551 tests pass.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new paused-specific branch (waitMs = this._states.paused ? 1000 : 0) changes runtime behavior but doesn’t appear to be covered by existing tests. Consider adding a regression test for a fire-once job with allowPast: true and a far-past date created with { paused: true }, then resume() it and assert it fires within a bounded time (and not after an overflow-sized delay).

[Hexagon]

@copilot apply changes based on this feedback

[Copilot]

Added regression test in 9d31329. The test creates a fire-once job with allowPast: true, paused: true, and a far-past date (2020-01-01), verifies it doesn't fire while paused, then calls resume() and asserts it fires within 2 seconds. All 552 tests pass.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.