AI Coding Agents
Reliability
Queue consumer safety in agent-generated code
September 27, 2026 - 2 minute read
Queue consumer safety depends on behavior under duplicate delivery, worker failure, and delayed acknowledgment. Agent-generated code can look correct in a unit test while still charging twice, sending duplicate mail, or losing work when the process exits between a side effect and an acknowledgment.
The delivery contract must come from the queue service. Amazon SQS documents at-least-once delivery for standard queues and tells consumers to be idempotent. That guarantee should shape the task specification and tests before a coding agent edits the handler.
Define queue consumer safety invariants
Write down the durable effect for one logical message. A payment event may create one ledger entry. An indexing event may move a record to a target version. A notification may record one send against a stable event identifier. The invariant must survive retries across processes, not only duplicate calls inside one test.
Choose the idempotency boundary beside the side effect. A database-backed consumer can claim a message identifier and apply the state change in one transaction. A remote API may provide its own idempotency key. An in-memory set is useful in a narrow test, but it does not protect multiple workers or restarts.
Keep the message identifier stable across retries. Generating a new key inside the handler defeats deduplication. Define what happens when the same identifier arrives with different content, since silently accepting conflicting payloads can hide producer defects.
Test queue consumer safety under interruption
Exercise the order of operations directly. Deliver the same message twice, fail after the durable write but before acknowledgment, and restart the worker. The final state should match one successful logical operation.
Test retryable and terminal failures separately. A transient dependency error may return the message to the queue. Invalid input usually belongs in a dead-letter path with enough context for diagnosis. Bound retry counts and backoff according to the service configuration so a poison message cannot consume a worker indefinitely.
Visibility timeouts and leases need tests that outlive the normal handler duration. If work can exceed the lease, verify renewal and cancellation behavior. If the worker loses ownership, prevent it from committing a stale result after another worker has taken over.
Batch consumers need a partial-failure case. Prove which messages are acknowledged when one item fails and whether successful items can reappear. The handler must preserve each message's idempotency boundary even when the queue API reports results for the batch as a group.
Review the complete delivery path
A pull request should include the queue's documented delivery semantics, acknowledgment point, idempotency store, retry policy, dead-letter behavior, and failure-injection results. Review producer and consumer changes together when message identifiers or schemas move.
Factory's Missions planning lets a team define validation contracts before implementation and place checks at milestones. For queue work, those checks can separate handler logic, infrastructure configuration, and restart tests. Factory's Automated QA can run API or CLI flows around the consumer and retain evidence.
Keep production replay and queue purging outside the coding task unless separately authorized. Safe code generation produces reviewable changes and isolated evidence. Operators still control actions that affect live messages.
