I removed every delete from my exactly‑once guard. Then the bugs moved.
Description and use
Removing delete operations, switching to generation-based claims, and dual age checks eliminated duplicate charges and ensured correct refund processing under high concurrency.
Problem
Exactly‑once processing guard failed under concurrency and stale claim scenarios, causing duplicate charges and missed refunds.
Outcome
Removed delete operations, switched to generation‑based claims, and added dual age checks, resulting in zero duplicate charges and reliable refunds under high concurrency.
Workflow
- 1. Workers attempt to create a claim file with os.open(..., O_CREAT|O_EXCL).
- 2. If claim exists, worker reads claim metadata and checks age using min(record_age, mtime_age).
- 3. If claim is stale, worker creates a new generation claim file without deleting the old one.
- 4. Workers process the charge only if they own the latest generation claim.
- 5. Refunds are processed after successful charge and logged; no duplicate refunds occur.
- 6. Tests validate concurrency, TTL handling, and clock drift scenarios.
Evidence
fixed generation: 0/20 double executions 16 workers x 40 trials: 0 double executions
claim age. A claim records when it was made. That record is written by the claim, so it can be wrong
- Record date: 2026-09-08T19:00:27.375Z