src/runtime/internal/task.ts (1)

68-79: waitUntil is only passed to task context — the cron callback never registers itself with the server lifecycle

The schedule runner passes waitUntil into task context (so tasks may opt in), but the cron callback itself never calls waitUntil(tasksPromise). In runtimes with graceful-shutdown semantics (e.g., Cloudflare-style), scheduled tasks can be interrupted if the server receives a shutdown signal, because nothing registers the in-progress work at the server level. Consider forwarding the aggregate promise:

♻️ Suggested approach

     new Cron(schedule.cron, async () => {
-      await Promise.all(
-        schedule.tasks.map((name) =>
-          runTask(name, {
-            payload,
-            context: { waitUntil },
-          }).catch((error) => {
-            console.error(`Error while running scheduled task "${name}"`, error);
-          })
-        )
-      );
+      const tasksPromise = Promise.all(
+        schedule.tasks.map((name) =>
+          runTask(name, {
+            payload,
+            context: { waitUntil },
+          }).catch((error) => {
+            console.error(`Error while running scheduled task "${name}"`, error);
+          })
+        )
+      );
+      waitUntil?.(tasksPromise);
+      await tasksPromise;
     });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/runtime/internal/task.ts` around lines 68 - 79, The cron callback starts
all scheduled runTask calls but never registers the aggregate work with the
lifecycle, so ongoing tasks can be terminated on shutdown; capture the
Promise.all result (e.g., tasksPromise = Promise.all(...)) and call
waitUntil(tasksPromise) from inside the Cron callback so the runtime knows about
the in-flight work; keep the existing per-task .catch logging but ensure you
pass the wrapped/aggregated promise to waitUntil after mapping schedule.tasks to
runTask(name, { payload, context: { waitUntil } }) so the Cron lifecycle is
properly awaited.