Conflict detection

What it is

Conflict detection is the rule that prevents two confirmed bookings from overlapping on the same asset. It is enforced on the server, not just by the app. That 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

Conflict detection applies to every member booking, whoever created it. An admin gets no exemption from it for their own flying.

A maintenance booking is the one exception, and it displaces rather than being refused. When an admin schedules maintenance over a member’s confirmed booking, the ordinary refusal does not apply: the server moves each overlapping confirmed booking to suspended in the same step that schedules the maintenance, and notifies the member. See Booking statuses and Airworthiness rules for what a suspended booking can still do and when it comes back.

There is one thing maintenance cannot displace: a booking already under way. If a member is in the air, or inside their booked window, the maintenance booking is refused outright instead, naming the booking in the way. Shorten the maintenance window, or wait for the flight to end.

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 app removes the rejected booking from your device automatically and sends you a notification that the slot was taken; to rebook, create a new booking for a free time.
When an offline edit that would move a booking onto an occupied slot reaches the server. The edit is rejected the same way, but the booking is not: your device is put back to the times the server is holding, and the notification says the change was not saved rather than that the booking was lost.

The rule

There are no user-facing fields. The underlying rule is:

For any asset, no two bookings with status confirmed may have overlapping time ranges.

The check is run on the server every time a booking is inserted, updated, or promoted to confirmed, so there is no way to slip past it from any client.

Behaviour rules

Confirmed-only. The check applies only to bookings in confirmed status. 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, the rejected booking is removed from the author’s device, and the author is notified that the slot was taken.