Overview
This PR is a stability fix, not a new feature. It closes a crash in the appointment-scheduling screens that happened when a user switched to a dental-clinic branch whose data had not yet been loaded in their current browser session.
The one-sentence version
Three places in the "how many appointment slots are free" logic assumed a branch's opening-hours data (branchData) was already loaded before reading it. If the user hit an appointment-scheduling screen a beat before that data arrived — most commonly right after switching branches — the app tried to read a property off undefined and crashed with an uncaught JavaScript error.
What actually changed
The PR adds defensive checks ("computation guards") in three spots so the UI degrades gracefully — showing a placeholder / empty state — instead of throwing:
getStartAndEndTimes()in the shared calendar-helpers module (used by
both the web app and the mobile app).
- The Available Slots button on the "repeat appointment" form
(CheckRepeatTimesAvailabilityButton, web only).
- The month view picker opened from the appointment form
(MonthlyCalendar, web only), which also had a second, related bug: it didn't recompute once the branch data finally did arrive.
No new screens, no new business logic, no new permissions. Every screen this PR touches already existed; this PR only makes them resilient to a timing gap that previously wasn't handled.
Who should read what
- Support / Training / Quality: read Walkthrough and
For Support / For Quality — this is the practical "what did the crash look like, how do I confirm it's gone" material.
- Engineering-adjacent readers: read Feature breakdown
for the exact root cause and the file:line references into the fix.
- Stakeholders / Marketing / Sales: read For Stakeholders
for the "why this matters" framing — this is a reliability fix for a visible crash, not a feature to promote externally.
This feature is unreleased at the time of writing; screenshots come from a pre-release sandbox build of this branch.