Commit graph

2 commits

Author SHA1 Message Date
9d87c129ad fix: make check-then-hold atomic against concurrent bookings (#4)
Two simultaneous requests for the same nights could both pass is_available()
before either wrote its held row, double-booking the dates. Wrap the
is_available -> create_booking pair in a per-room asyncio.Lock
(_room_locks[room_id]) in services.request_booking, which both the HTTP and
RPC doors funnel through. FX + invoice creation stay outside the lock, so it
covers only the DB critical section.

Single-loop scope (LNbits runs one worker); documented the multi-worker
caveat (needs a DB-level guard) in event-flow.md and the crud.is_available
note.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019VUQCfdqiLSsFS2jcGnaFD
2026-07-19 17:08:43 +02:00
e7fabd57bf feat: CRUD + availability arbiter
Room/booking/block persistence, and is_available() — the authority for
whether a range is free: room active AND no occupying booking or block
overlaps [check_in, check_out) (half-open, so back-to-back stays are fine).
expire_stale_holds() frees dates for lapsed unpaid holds.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019VUQCfdqiLSsFS2jcGnaFD
2026-07-19 00:16:39 +02:00