Timeouts

Bound each execution attempt; timed-out jobs fail and may retry.

timeoutMs bounds a single execution attempt. The dispatcher races the task against the timeout (tokio::time::timeout); if it elapses, the attempt is marked failed and timed-out.

queue.task("scrape", scrape, { timeoutMs: 30_000 });

queue.enqueue("scrape", [url], { timeoutMs: 10_000 }); // per-job override

A timeout counts as a failure: it consumes a retry and, if retries remain, the job is re-enqueued. When the budget is exhausted the job dead-letters with timedOut: true on the outcome — passed to the onRetry / onDeadLetter middleware hooks and the job.retrying / job.dead events, so handlers can tell a timeout apart from any other error.

For async tasks, the timeout aborts the task's AbortSignal; honor it (e.g. pass signal to fetch) so the underlying work actually stops, not just the bookkeeping.

Always set a timeout on production tasks — without one, a wedged task can hold a worker slot indefinitely.

Coming from BullMQ? BullMQ has no first-class per-job timeout option — processors typically race their own work against a manual Promise.race (or rely on lockDuration as an indirect signal). flexiq's timeoutMs is enforced by the dispatcher directly, no manual race needed.