Andrey Tverdomed

Thanks, that's the gap I care about most too. There's no magic number. I set the timeout comfortably above the slowest normal booking call, so a slow but healthy call never gets its claim released early. For a calendar API that usually means a few minutes rather than seconds. The important part is what the cleanup does when the timer fires: it checks the real calendar first and only releases the claim if no booking exists. A short timeout just means more checks. A long one holds the slot longer after a real crash.

Good catch, and you're right that the re-check before the write narrows this but doesn't close it. Run A can still return late after the cleanup job released the claim and run B took the slot. We haven't tested that exact path, so I won't claim we have. The fix is what you describe: a generation counter on the claim row, incremented on every claim and carried by the executing run, with the final write conditioned on it (WHERE slot_id = :slot AND generation = :gen, zero rows updated means stale owner, abort). Where the calendar API supports it, an idempotency key or ETag precondition does the same on the external side.