For Stakeholders

Why this matters

Appointment scheduling is core, daily-use functionality for every clinic on the platform. A crash in that flow — even a narrow, timing-dependent one — is the kind of bug that erodes trust fast: it looks like the whole app is broken, not like one edge case in one form. Multi-branch clinics (clinics running more than one location) were the population exposed to it, since the trigger is switching between branches.

Risk profile

• Likelihood of prior customer exposure: this fix landed pre-release,

so there's no confirmed customer-facing incident tied to it. The precondition (switching to a branch not yet loaded this session, immediately hitting one of three specific screens) is narrow but not exotic — any multi-branch clinic staff member switching branches during their normal workflow could plausibly have hit it.

• Severity: high per-occurrence (a full page crash requiring a reload,

with no in-app recovery), but scoped to a specific timing window rather than a persistent or data-corrupting failure. No data loss risk — this is a read-path crash, not a write-path one.

• Scope of the fix: three files, all defensive guards. No behavior

change for the common case (branch data already cached, which is most usage after the first branch switch each session).

What's not resolved

The fix closes the crash in the three places it was reported and directly reachable. One related code path — the deeper slot-calculation helpers used once the "Available Slots" modal is actually showing results — still lacks the same guard (see The three guards, in detail for the specifics). It's a narrower, harder-to-hit window than the one this PR fixes, and QA should decide whether it needs its own follow-up fix.

Bottom line

Small, low-risk, high-value fix: no feature or business-logic change, a narrow but real crash closed, one adjacent edge case flagged for follow-up rather than silently left unfound.