A Service Bus worker produced the same external side effect twice. The second attempt has the same MessageId, DeliveryCount 2, and a lock-renewal failure after the provider call succeeded. How would you diagnose, contain, and repair it?

Debug duplicate Azure queue processing after lock loss

Diagnoses duplicate processing from Azure Service Bus lock loss or Storage Queue visibility behavior without repeating generic idempotency theory.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

For a Service Bus case, I start with one duplicated side effect and inspect MessageId, delivery count, lock-lost or renewal events, settlement outcome, worker instance, and the external provider reference. If delivery count increased after the provider succeeded but before CompleteMessageAsync succeeded, this is redelivery of the same message. I pause unsafe consumption and reconcile the provider before allowing another effect.

Full answer below

Practice focus

Azure delivery evidence, lock loss, settlement, redelivery, provider idempotency, reconciliation, and failure-injection proof.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A worker can finish the business side effect yet fail before message settlement or durable completion. Redelivery is correct broker behavior, so duplicate safety must exist at the side-effect boundary.
For a Service Bus case, I start with one duplicated side effect and inspect MessageId, delivery count, lock-lost or renewal events, settlement outcome, worker instance, and the external provider reference. If delivery count increased after the provider succeeded but before CompleteMessageAsync succeeded, this is redelivery of the same message. I pause unsafe consumption and reconcile the provider before allowing another effect.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The consumer stores a durable operation record and reuses the provider idempotency key, so redelivery returns the known outcome instead of charging or sending twice. Lock duration and renewal fit measured work, and long processing is split or checkpointed rather than hoping the lock survives. Service Bus duplicate detection can suppress repeated sends with the same message id inside its configured window, but it does not prevent redelivery after lock loss and does not replace consumer idempotency.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming every duplicate effect came from broker redelivery.
Replaying messages before checking external provider state.
Completing the message before the durable local transition.
Treating a longer lock timeout as a substitute for idempotency.

A Service Bus worker produced the same external side effect twice. The second attempt has the same MessageId, DeliveryCount 2, and a lock-renewal failure after the provider call succeeded. How would you diagnose, contain, and repair it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Was this drill useful?

Found this answer useful?

Human editorial direction

A Service Bus worker produced the same external side effect twice. The second attempt has the same MessageId, DeliveryCount 2, and a lock-renewal failure after the provider call succeeded. How would you diagnose, contain, and repair it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Start a conversation

Was this drill useful?

Found this answer useful?

Human editorial direction