fix: prevent cron from permanently dying after handler errors (#16219)

When any error occurs during a cron job, the cron stops firing
permanently and never recovers until the process is restarted.

This happens because of a bug in croner v9 combined with missing error
handling in the cron setup. Croner's `protect: true` option sets an
internal `blocking` flag before running the handler and only clears it
after the handler completes. In v9, if the handler throws, the flag is
never cleared because there's no `try/finally` around it. Every future
cron sees `blocking = true` and skips, so the cron is dead forever.

Even without the croner bug, the error from the handler was propagating
as an unhandled promise, which can crash the process.

One example where this affected us was if there is a db error while
running the job. Even if that error is temporary and would be resolved
during the next run, the cron job would no longer run until the process
is restarted.

## Two changes fix this:

- Bumped croner from v9 to v10, which wraps the handler in `try/finally`
so the `blocking` flag is always cleared regardless of whether the
handler throws. This was a confirmed bug in v9

- Added the `catch` option to the Cron constructor, which tells croner
to catch handler errors and pass them to a callback instead of letting
them escape as unhandled rejections. The callback logs the error via
`payload.logger.error` so it's visible in application logs.


---
- To see the specific tasks where the Asana app for GitHub is being
used, see below:
  - https://app.asana.com/0/0/1213983836266032

Author: AlessioGr

packages/payload/package.json

@@ -107,7 +107,7 @@
     "busboy": "^1.6.0",
     "ci-info": "^4.1.0",
     "console-table-printer": "2.12.1",
-    "croner": "9.1.0",
+    "croner": "10.0.1",
     "dataloader": "2.2.3",
     "deepmerge": "4.3.1",
     "file-type": "21.3.4",

packages/payload/src/bin/index.ts

@@ -43,6 +43,8 @@ export const bin = async () => {
       {
         // Do not run consecutive crons if previous crons still ongoing
         protect: true,
+        // TODO: Remove this compatibility option in 4.0. This only exists to ensure backwards-compatibility between Croner v9 and Croner v10 cron syntax
+        sloppyRanges: true,
       },
     )
 

packages/payload/src/index.ts

@@ -754,8 +754,13 @@ export class BasePayload {
               })
             },
             {
+              catch: (err) => {
+                this.logger.error({ err, msg: 'Error in job queue cron job handler' })
+              },
               // Do not run consecutive crons if previous crons still ongoing
               protect: true,
+              // TODO: Remove this compatibility option in 4.0. This only exists to ensure backwards-compatibility between Croner v9 and Croner v10 cron syntax
+              sloppyRanges: true,
             },
           )
 

packages/payload/src/queues/operations/handleSchedules/index.ts

@@ -141,7 +141,10 @@ export function checkQueueableTimeConstraints({
     ? queueScheduleStats?.tasks?.[taskConfig.slug]?.lastScheduledRun
     : queueScheduleStats?.workflows?.[workflowConfig?.slug ?? '']?.lastScheduledRun
 
-  const nextRun = new Cron(scheduleConfig.cron).nextRun(lastScheduledRun ?? undefined)
+  const nextRun = new Cron(scheduleConfig.cron, {
+    // TODO: Remove this compatibility option in 4.0. This only exists to ensure backwards-compatibility between Croner v9 and Croner v10 cron syntax
+    sloppyRanges: true,
+  }).nextRun(lastScheduledRun ?? undefined)
 
   if (!nextRun) {
     return false