fix: Keep one unusable event date from stopping all background events

[MajorLift]

Summary

• A background event whose date cannot be parsed stops all background-event scheduling. #startTimer computes NaN milliseconds, both of its guards (ms > DAILY_TIMEOUT and ms <= 0) are false against NaN, and it reaches new Timer(NaN), which throws TypeError: Can't start a timer with NaN time.
• That throw escapes #reschedule's loop. Every event after the bad one in iteration order is never scheduled, init throws, and because the daily timer's callback is #reschedule(); #start();, the re-arm is skipped too, so scheduling stops for the rest of the session.
• In production that date is null, and getExecutionDate produces it. A duration is valid however large it is, so ISO8601DurationStruct accepts something like P1000000Y; adding it to the current time overflows the timestamp, which marks the DateTime invalid, and toISO() returns null for an invalid DateTime. plus keeps the static type valid, so nothing on that path is typed as nullable and the null reaches state as the event's date.
• Two changes. getExecutionDate throws rather than returning null, so the value is never stored. #startTimer throws a descriptive error for a non-finite interval, and #reschedule catches per event and reports through logError, so an unusable date already in state cannot strand the others.

Observed in Sentry as METAMASK-XREK, METAMASK-YQT5 and METAMASK-ZXFV: 15 events in the 90 days to 2026-09-16, on extension 13.35.1 through 13.47.0, Chrome MV3 and Firefox MV2.

MetaMask/snaps#3373 (properly catch cronjob errors during initialization) handled the asynchronous case, a Snap rejecting during the daily check-in. This is the synchronous one: a throw from scheduling itself, which that catch does not reach.

MetaMask/snaps#4107 (reduce cronjob write churn by persisting dates separately) carries the containment changes alongside a breaking addition to CronjobControllerStateManager. They are independent of that addition and non-breaking, so this lands them without it; #4107 can drop them once this merges.

Test plan

• New test throws an error for durations past the representable date range: P1000000Y and PT99999999999999S throw instead of returning null.
• Negative control for it: with the guard reverted, the test fails on the missing throw; restoring the guard passes it, so the assertion is load-bearing.
• Existing test schedules the remaining events when one of them has an unusable date: two stored events, the first unusable. init does not throw, and the healthy event executes while the broken one does not.
• Negative control for that one: with the source reverted to main, it fails with TypeError: Can't start a timer with NaN time escaping init.
• 35 tests pass across both cronjob suites. eslint and prettier clean on the changed files.
• Package suite run with coverage: no changes in coverage percentages detected, so coverage.json is unchanged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.60%. Comparing base (7e3d201) to head (7ea8e3b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4120   +/-   ##
=======================================
  Coverage   98.59%   98.60%           
=======================================
  Files         429      429           
  Lines       12497    12503    +6     
  Branches     1976     1977    +1     
=======================================
+ Hits        12322    12328    +6     
  Misses        175      175           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[FrederikBolding]

Suggested change

	if (Number.isNaN(ms)) {
	if (!Number.isFinite(ms)) {

Perhaps we can check that the result is finite in general?

[MajorLift]

Fixed here: fc52dcc

[FrederikBolding]

Instead of throwing should we just return;?