20 lines
1.1 KiB
Markdown
20 lines
1.1 KiB
Markdown
# 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.
|