---
title: "Comment by Darius Tran on \"Your Distributed Lock Expired. Your Code Didn't.\" | Hashnode"
description: "The point that a longer expiry only delays the failure is the part people skip. The stale writer has no idea it lost the lease, so only the destination can refu"
url: "https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6ad07e155ba71273f3ad89e6"
---

[Discussion](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56)

Comment [Your Distributed Lock Expired. Your Code Didn't.](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56)

[Darius Tran](https://hashnode.com/@dariustran)

[Oct 15](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6ad07e155ba71273f3ad89e6)

The point that a longer expiry only delays the failure is the part people skip. The stale writer has no idea it lost the lease, so only the destination can refuse it.

The same thing shows up with agents that retry tool calls. A paused or timed-out run wakes up and writes after a newer run already did.

For side effects the database can't fence, like an email or a payment call, do you lean on idempotency keys with the provider, or an outbox so only the current owner ever sends?

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 15](https://hashnode.com/posts/your-distributed-lock-expired-your-code-didn-t/6acde157ae82c4dc9a01de56/comment/6ad07e155ba71273f3ad89e6#reply-6ad07f16e8a7ddf6b9bdc6f8)

Id prob combine an outbox with provider side idempotency. The fenced database transaction records the accepted result and its outbound intent together, so a superseded worker cant enqueue new work. The dispatcher then retries that intent using a stable idempotency key for the logical operation. An outbox doesnt guarantee "only the current owner ever sends". An intent accepted before ownership changed can still be delivered afterwards, and a dispatcher can itself pause with a request in flight. If that previously accepted action must now be rejected as obsolete, the destination needs a version or conditional operation check too. Idempotency alone wont establish that. Where the provider offers no check, you have to decide whether accepted intents remain valid or whether the workflow needs cancellation, reconciliation or compensation.