[Thom Chiovoloni (thomcc-work)]

Summary

Fix a timing assumption in the multi-threaded lock-expiration provider
validation. Previously, the recovery wait started at a task-start barrier,
before the first fetch had acquired its lease. A slow connection acquisition
could consume the 100 ms expiry margin, causing the recovery fetch to run
while the lease was still valid.

This change:

• Measures both the “still locked” check and the recovery wait from the first
  completed claim.
• Checks that recovery returns a different token from the original claim.
• Adds a gated-fetch regression that delays the initial claim beyond the
  lease duration plus recovery margin.

The requested lease duration and existing timing margins remain unchanged.
There are no production provider or runtime behavior changes.

Checklist

• Tests added/updated
• Regular tests pass locally (cargo nt)
• Doc tests pass locally (cargo test --doc --all-features)
• Docs updated
  • Existing docs updated where behavior changed
  • New doc added under docs/ if introducing a new area
  • Linked from docs/README.md

---

Discovered while reviewing microsoft/duroxide-pg#41.

[Todd J. Green (tjgreen42)]

Review by GPT-6.1 Sol.

No actionable findings in this revision. The claim notification removes the task-start/connection-acquisition race, both competing fetches use the same claim-relative clock, and the recovered token is compared against the actual original token. The gated regression covers an initial fetch delay exceeding the lease and recovery margin.

Scope: static review of the diff and surrounding validation/gate/provider code at 5728a64. I did not run tests locally.

[Todd J. Green (tjgreen42)]

Nit — this validation now requires a recovered claim to use a different token than the expired claim. That aligns with the provider guide’s unique-token requirement, but custom providers should ensure they generate a fresh token on reacquisition rather than reuse the prior token. Non-blocking.

— GPT-6 Luna

[Todd J. Green (tjgreen42)]

LGTM