How to review an AI-written dead letter queue worker

To review an AI-written worker that adds a dead letter queue, follow one message through every outcome: success, a temporary failure, a permanent failure, a worker crash, and a later redrive. The main question is not whether the code declares a retry count. It is when the original message is acknowledged and whether the job can be lost or its side effect repeated at each handoff.

Suppose a worker sends an order confirmation email. An agent adds three retries with exponential backoff and sends an exhausted job to a dead letter queue. The order and email worker are a hypothetical service, not Review Assist features. The PR is ready for review only when its delivery contract, failure classification, and recovery path are visible in code and tests.

Draw the delivery state machine

Identify the source queue, worker, side effect, retry scheduler, and dead letter queue in the actual repository. Write down who moves the message, who tracks attempt count, and who acknowledges the original delivery. Queue providers differ: some move a message after a receive threshold, while an application can explicitly republish it. The review must follow the mechanism this PR uses, including what happens between publishing a replacement and acknowledging the source.

For a successful send, ask what durable evidence says the email went out before the worker acknowledges. For a failed send, ask whether the worker leaves the message available for another attempt or writes a durable retry first. If publish-to-retry succeeds and acknowledgment fails, both copies may run. If acknowledgment succeeds before the retry is durable, the job may disappear. A single process-level happy-path test will not settle either window.

State the delivery guarantee honestly. With at least once delivery, a job can arrive again after a crash or timeout, even if the first attempt completed its external call. The email operation needs a stable job identity and an idempotent or reconciled send path appropriate to the provider. A retry counter in memory resets on restart and is not enough to bound attempts. If the service cannot make the side effect idempotent, document the duplicate risk and a way to detect it before calling the worker safe.

Separate failures that can recover from failures that cannot

A timeout, a rate limit, and a malformed email address should not follow the same retry policy. Inspect the actual errors returned by the dependency and the worker's classification. Timeouts can hide an accepted send, so blindly sending again may duplicate mail. A permanent validation error should go to an inspectable failure state without burning retries. An unknown error needs a deliberate default, not a catch-all that quietly acknowledges it.

Check delay, jitter, attempt limit, and total age together. Exponential backoff can reduce synchronized pressure, but a cap and jitter matter when many jobs fail at once. A queue visibility timeout or lease must cover the work duration or be extended while the job runs; otherwise another worker can receive the same message before the first finishes. Compare these values with the service's actual timeout and recovery objective. Avoid accepting a plausible-looking constant without that comparison.

Treat the dead letter queue as work to be owned

A dead letter queue only preserves a failed message if the move itself succeeds and someone notices it. Verify the payload retains the identifiers and failure context needed to diagnose the job, while excluding secrets and unnecessary personal data. Check who can read the queue, how long messages remain, and whether an alert fires on new failures or age. A queue that silently fills is delayed data loss for the user.

Redrive is a separate operation. After fixing the defect, can an operator select a message, inspect why it failed, and replay it without losing its stable identity? A bulk redrive may send thousands of jobs back into the same broken worker or overwhelm a recovered dependency. Ask for a bounded rate, an owner, and a stop condition. If the payload shape changed since the original failure, the replay path must handle that version or explicitly quarantine it. The PR does not need an elaborate console, but it does need a credible recovery procedure.

Ask for tests at the handoffs

• •Make the side effect succeed, then crash before acknowledgment. Deliver the same message again and assert the intended duplicate behavior.
• •Fail the publish to the retry or dead letter queue. Assert that the source job remains recoverable rather than disappearing.
• •Run two workers or equivalent independent consumers against a short lease. Assert whether the job can overlap and how the side effect is protected.
• •Exercise a transient error, a permanent error, and an unknown error. Assert attempt count, delay, final destination, and the event that triggers an alert.
• •Redrive one exhausted job after a fix, then try an older payload version. Verify the job identity and operator-visible result.

Test the queue adapter and worker boundary where possible, not only a helper that computes delay. Use a controllable clock and an injected failure at each publish and acknowledgment step so the test does not wait for real backoff. A dashboard showing zero failed jobs after the happy path is not evidence for the crash windows.

Make the review decision explicit

In Review Assist, use problem.user_asks and approach.requirements to find the promised delivery behavior. Inspect tour anchors for the worker, queue configuration, and retry or dead letter writes. Read assumptions for claims about provider acknowledgment or idempotency, and verification.not_verified for the crash and redrive paths. The coverage check shows whether counted hunks have explanations. It does not execute the worker or prove that the queue transition is atomic. Use the untested-path review when one of these windows has no evidence.

A review comment the author can close is: “The worker publishes a retry and then acknowledges the original message. What happens if the publish succeeds but the acknowledgment fails? Please test that handoff with the real queue adapter or a failure-injected equivalent, show how a duplicate is recognized, and document how an exhausted job is alerted and redriven.”

Approve when every outcome has a durable next state, repeat delivery cannot silently repeat an unacceptable side effect, the retry budget matches the dependency's failure modes, and someone owns the dead letter queue and its redrive. If those are still assumptions, keep them visible in the PR rather than treating a green coverage count as a delivery guarantee.