1.1 KiB
Resource-backed appointments are guarded by occupancy, not the doctor slot key
An appointment's active_slot_key is doctor_id:slot_start under a unique index, which assumes the
doctor is the thing being occupied. Once a doctor supervises several devices that assumption breaks:
the second booking in the same hour on a different device is rejected. Resource occupancy already
guards those bookings at the database level via uniq_bucket_resource_seat (resource_id, bucket_at, seat), so an appointment that carries a resource leaves active_slot_key null and lets occupancy be
the sole authority; only resourceless legacy bookings keep the doctor key.
Considered Options
Rekeying on the resource (r{resource_id}:{slot_start}) was rejected because it silently defeats
ClinicResource.capacity: a room seating three would reject its second patient, and the unique index
knows nothing about seats, buffers, or setup and cleanup time.
Consequences
Any booking path that omits the resource falls back to the doctor key. Those paths have to be found and made resource-aware, or they end up with weaker protection than they have today.