Past dates visually unselectable and rejected client-side before API call
Why it matters
Clickable past dates send doomed POST requests to the booking API, wasting backend cycles, polluting logs with 4xx errors, and surfacing generic server-side failures that erode user trust. Customers who manage to submit a past date hit a confusing rejection screen mid-flow, abandon the booking, and never return. This is a preventable user-experience regression that also inflates telemetry noise and masks real availability failures in your error-rate dashboards.
Severity rationale
Low because server-side validation still blocks the booking, so the impact is UX friction and log pollution rather than data corruption or revenue loss.
Remediation
In your calendar slot component, compute isPast from new Date(slot.time) < new Date() once per render, then apply both a disabled attribute and a visually distinct class (opacity-50 cursor-not-allowed) when true. Short-circuit the click handler before any fetch call fires. See src/components/CalendarSlot.tsx:
const isPast = new Date(slot.time) < new Date()
if (isPast) { toast.error('This date has passed'); return }
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