The booking form recovers from a slot conflict by refreshing the calendar

The BookCall component has a four-step flow — date, time, details, confirmed. Steps one through three collect information. Step four shows the confirmation. The interesting behaviour is what happens between step three and step four when something goes wrong. When the user submits their details, the handleBook function sends a POST to the booking API with the selected start time. If another person booked the same slot between the page load and the submit click, the API returns a 409 status code. The component checks for that specific status. When it sees a 409, it does three things in sequence. First it clears the selected slot from state. Second it sends the user back to the time picker step. Third it immediately fires a fresh availability request for the same date to get the updated slot list. The user sees the time grid refresh with the taken slot removed. They pick another time and try again. The flow does not restart from the date step because the date is still valid — only the specific time slot was taken. The re-fetch runs inside the same error handler as the status check, chained after the step and slot state updates. The submittingRef flag — a useRef, not a useState — prevents double submission during the brief window between the button click and the API response. A ref is synchronous. A state update is batched. If the guard used state, two rapid clicks could both read false before either update lands. The ref reads true immediately after the first click sets it. The finally block resets both the booking loading state and the ref so the form is ready for the next attempt.