A retry loop is an availability problem before it is a queue-setting problem: it can spend all worker slots on work that cannot succeed and raise the age of healthy messages. Short answer: give each logical background job one finite attempt budget, classify permanent failures before another delivery is scheduled, and keep dead-letter queue redrive as an operator-controlled recovery action. For a Node.js worker whose retries do not stop, start by proving which counter is advancing; the broker, the worker library, and application code can each maintain a different one.
Backoff changes when work returns. It does not decide that work should stop returning.
How should a Node.js worker troubleshoot background job queue retries that do not stop?
Follow one message across the whole path before changing a maximum-attempt setting. Record its immutable message ID, logical job ID, enqueue timestamp, broker delivery count, application attempt count, error class, worker version, and acknowledgement outcome. A handler that catches an exception and creates a replacement job can produce a stream of apparent first attempts. An expired visibility lease can cause another delivery without a new enqueue. A redrive can introduce a fresh physical message while the original business operation is still the same.
