Availability recalculated after each booking without requiring full page reload
Why it matters
When the calendar does not refresh after a successful booking, the just-booked slot still appears green and selectable. A second customer in the same session clicks it, hits a 409 conflict from the server, and sees a generic error. This creates double-booking races, duplicate conflict-handling work, and a confusing 'did my booking go through?' moment that drives support contacts. The defect also misleads the original user, who may refresh and fear their booking failed.
Severity rationale
Low because server-side uniqueness constraints prevent actual double bookings; impact is confined to UX confusion and retry friction.
Remediation
After the booking POST resolves with response.ok, immediately refetch availability (or call queryClient.invalidateQueries(['availability']) with React Query) before showing the success toast. Prefer cache invalidation over manual setSlots so stale data anywhere in the tree clears too. See src/hooks/useBooking.ts:
if (response.ok) {
await queryClient.invalidateQueries({ queryKey: ['availability'] })
toast.success('Booking confirmed!')
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Calendar & Availability Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from booking-calendar-availability·automated