Bun.cron() for Sume jobs: an OS scheduler is not a job store

Use Bun 1.4's Bun.cron() to run a periodic reconcile pass over Sume job ids you stored yourself, not as the thing that knows which jobs are in flight. The Bun 1.4 release post lists Bun.cron() as OS-level scheduling through crontab, launchd or Task Scheduler, and an OS scheduler only fires a command on a schedule: it has no record of a Sume job unless your submit step wrote the id somewhere durable.

Bun's side comes from the Bun 1.4 release post, which I read on 2026-10-03 and which gives no signature or options for Bun.cron(), so I describe only what it lists. Sume's side comes from Jobs and results, Generation admission and Errors and rate limits. I did not run Bun 1.4.

What should the scheduled pass do?

Read the unfinished job ids from your store, call GET /v1/jobs/{id}/status for each, and stop tracking a job when terminal is true. For a completed job fetch result_url once result_ready is true; for failed or canceled read the failure from the job record. Never resubmit the paid request because a pass found nothing: Sume's docs say not to resubmit just because a local process timed out.

Cron granularity is coarse. Crontab's finest step is one minute, while next_poll_after_seconds in a status response can be shorter, so treat the scheduled pass as a safety net behind webhook mode, not as your primary wait. Status reads have their own rate limits; Sume's docs call those polling backpressure, so cap how many ids one pass reads and honor retry-after on 429.

What if the pass hits queue_full?

A reconcile pass that also resubmits missing work can hit 429 queue_full, which means the workspace has no remaining accepted generation capacity. Poll existing jobs until one is terminal, cancel queued jobs you no longer need, then retry with the same Idempotency-Key. 429 rate_limited is a separate case: back off using retry-after.