Conflict detection
What it is
Section titled “What it is”Conflict detection is the rule that prevents two confirmed bookings from overlapping on the same asset. It is enforced by the database, not by the app — which means it still holds when two members try to book the same slot at the same time from two different devices, and when a booking is created while offline and syncs later.
Who can use it
Section titled “Who can use it”Conflict detection applies to everyone. There is no bypass for admins or owners — the constraint is enforced at the database level by a Postgres exclusion constraint.
Where to find it
Section titled “Where to find it”You never see conflict detection directly. You encounter it:
- When you try to create a confirmed booking that overlaps an existing confirmed booking — the create dialog returns an error explaining the conflict.
- When an offline booking created on a phone reaches the server and is rejected because another confirmed booking landed first. The rejected booking is left in the author’s device with a sync error; the author resolves it by editing the times or cancelling.
Fields / options
Section titled “Fields / options”There are no user-facing fields. The underlying rule is:
For any asset, no two bookings with status
confirmedmay have overlapping time ranges.
In Postgres terms, the bookings table carries an exclusion constraint using btree_gist on asset_id and tstzrange(start_time, end_time), with a WHERE status = 'confirmed' clause.
Behaviour rules
Section titled “Behaviour rules”- Confirmed-only. The constraint applies only to bookings in the
confirmedstatus. Tentative and pending bookings can overlap freely, with each other and with confirmed bookings. This is the whole point of the tentative model — see Tentative bookings. - Same-asset only. Two confirmed bookings on different assets can happily overlap. The asset is the thing being reserved.
- Inclusive of start, exclusive of end. A booking from 09:00 to 10:00 does not conflict with one starting at 10:00.
- Cross-status transitions. When a pending booking is approved or a tentative is confirmed, the check runs at that point. If another booking has slipped in and taken the slot, the promotion fails and the booking stays in its previous state.
- Offline safety. If a member creates a booking offline and another member takes the same slot online before the first device reconnects, the offline booking is rejected on sync. Last-write-wins does not apply to booking conflicts — the server rejects the later write.