Make check-then-hold atomic (double-booking race) #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
crud.is_available()followed by writing theheldbooking is a critical section. Two concurrent requests for the same nights can both pass the availability read before either writes → double booking. MarkedTODO(concurrency)inviews_api.py:api_request_booking.Options
db.reuse_conn/async with db.connect()), orasyncio.Lockaround the section (simpler; single-process only — fine for one castle instance).Because the availability check counts
heldas occupying, once one request writesheldthe loser's re-check fails →409. The fix only needs to make the read→write atomic.Acceptance
A test firing two simultaneous requests for identical dates results in exactly one
heldbooking and one409.Shipped in PR #9 (per-room
asyncio.Lockaround check-then-hold), with a real-DB concurrency regression test in #10 and the migration test in #15; released in catalog v0.1.0. Closing (auto-close phrasing never fired).