this doesnt use the ttl....at all.

[keen99]

spent some time with this in a POC this week. looked like a great solution.

it has heartbeats, a ttl, etc.

but as best I can tell - it depends exclusively on dynamodb to remove the record based on the TTL - which is guaranteed to happen in the span of days.

so, as an example:

a running container dies, setddblock isn't notified to shut down. the last heartbeat updated the ttl to +15s.

now another container starts before the 15s expire - checks the lock, it's locked, all good.

next attempt - after the 15s expire. the record is expired, and available to be deleted by ddb, but still exists.

this code doesnt check the ttl, only that the record exists (and an expired record is treated the same by GetItem with ddb)

further checks continue to fail until the eventual cleanup happens (in my testing, ~~10 minutes. but the documentation guarantees typically within a few days of their expiration, so we could be locked and dead for a long time.

It feels to me like we should be validating against the TTL, not just existence of the record....

the eventual removal is great but it's not an automatic unlocker.

[mashiike]

Hi, sorry for the late response — and thank you again for raising this issue and the discussion around it!

The core philosophy behind setddblock comes from the behavior of setlock.
In setlock, if something goes wrong (e.g., the process crashes or exits abnormally) and a lock file remains, the lock is not automatically cleared — it must be manually deleted by a human.

setddblock was designed with the same idea in mind.
If a lock item remains in DynamoDB due to some issue, the expectation is that an operator will manually remove it from the AWS Console.
The DynamoDB TTL feature was introduced mainly for convenience, to let items be automatically deleted after some time (for example, after a day).
It was never intended to serve as an immediate or authoritative signal for lock expiration.

From that perspective, the approach proposed in PR #168 —
which allows a lock to be reacquired immediately once its TTL has expired —
felt a bit inconsistent with the original setlock philosophy.
There is also a practical concern about clock drift and TTL deletion delay,
since DynamoDB’s TTL cleanup is asynchronous and may take minutes or even hours.

To reconcile both sides, I’ve implemented PR #183,
which introduces an optional ExpireGracePeriod setting.

• When ExpireGracePeriod <= 0 (the default), the existing behavior remains —
  locks are not forcefully reacquired and rely solely on DynamoDB TTL cleanup.
• When ExpireGracePeriod > 0, once both the TTL and the additional grace period have passed,
  the lock can then be safely reacquired.

This way, users who prefer the behavior described in this issue can explicitly opt in
without changing the conservative default that respects the setlock design principles.

Again, thank you for taking the time to report and propose improvements —
your feedback was very helpful in clarifying the design direction of this project 🙏