IMQOptions.safeDeliveryTtl property

The longest (in milliseconds) a message may be worked on before it is treated as abandoned and moved back onto the queue.

Signature:

safeDeliveryTtl?: number;

Default Value

300000

Remarks

Set it to the longest a handler in this system can legitimately take, with headroom. A slow upstream is the usual reason for a large value — a data vendor with no job API, screen-scraping behind an HTTP call, anything that can take minutes — and a budget below that reclaims a message from a worker still legitimately working on it, handing somebody else a duplicate.

This is the **only** thing that recovers a message from a worker that is alive, connected and serving other messages while one handler has wedged on this one. Death of the whole process is caught separately and far faster, by the owner leaving the broker's client list, so this value does not govern how quickly an ordinary crash is recovered from.

Two internals follow this value but deliberately do not scale with it:

• The watcher's maintenance sweep — which recovers abandoned leases and drives the IMQOptions.cleanup pass — runs on IMQOptions.watcherCheckDelay, so a dead worker is still noticed within seconds however generous the budget is. Setting this to null or undefined disables that sweep altogether, so neither lease recovery nor cleanup runs. - The reader's blocking pop is half this value capped at 5000 ms, with a 100 ms floor. The cap matters: a lease deadline is stamped before the pop that fills the key, so an uncapped wait would hand a message a sizeable part of its budget already spent.

Read this page as plain markdown — no HTML, no navigation. For pasting into an LLM, or for an agent to fetch.