The booking flow recovers when a slot gets taken

The book-a-call component is a four-step state machine — date, time, details, confirmed. Pick a day from the calendar, pick a time from the available slots, enter your name and email, confirm. If everything works, you land on a confirmation screen with a Google Meet link. But the interesting part is what happens when it does not work. Between selecting a slot and hitting confirm, someone else might book the same time. When the API returns a 409 conflict, the component does not show a generic error and give up. It sends you back to the time picker, re-fetches the availability for that date, and renders the updated slot list with the taken slot removed. You pick another time and try again. The whole recovery happens without leaving the component or losing your name and email. Underneath the conflict handling, a useRef flag prevents double submissions. The ref check runs synchronously before any async work starts, so two rapid clicks cannot both enter the fetch call. The state-based booking flag handles the visual feedback — disabling the button and showing Booking... — but the ref handles the actual guard. The finally block resets both the ref and the state so the form is always recoverable. One component, four steps, one ref, one conflict recovery path.