The bug report was specific: a practitioner had ended up with two appointments in the same slot after a bulk reschedule. That's the kind of thing that shouldn't be possible in a scheduling app, so my first assumption was that I'd find a one-off mistake somewhere in the bulk-reschedule code.
What I actually found was more interesting. Local Medical Diary already had a solid pattern for preventing exactly this: CreateAppointment, UpdateAppointment, CreateRecurringSeries, PostAppointmentRecurringByID, DuplicateAppointment, PutGroupAppointment, and ReschedulePortalAppointment all took a Postgres advisory lock before checking whether the new time overlapped an existing appointment for that practitioner. Seven endpoints, same guard, consistently applied. Bulk reschedule — which can move up to 200 appointments at once via a shift or a new start time — had none of it. It just moved the times and saved.
So this wasn't really a bug in the sense of "wrong logic." It was a gap: a newer endpoint had been added without inheriting the safety check the rest of the codebase had already agreed on. That's a different kind of thing to fix, because the fix isn't "figure out the correct behavior" — the correct behavior is well established six times over. The fix is "apply it correctly to a batch operation," which has its own wrinkle: you can't just check each appointment in the batch against the whole table, because a batch of appointments legitimately shifts together and shouldn't collide with itself.
The guard I added takes the same advisory-lock-plus-overlap-count approach as the other seven, scoped to exclude the appointments already in the current batch. A uniform time shift preserves the relative gaps between appointments, so members of the same batch can't newly collide with each other — only a collision with something outside the batch is a real conflict. I kept the function's existing partial-success convention too (some appointments succeed, some get reported as failed) rather than switching the whole operation to all-or-nothing, since that's what the rest of the endpoint already did.
The test I wrote reschedules one appointment in a batch directly onto a slot where the same practitioner already has a separate, real appointment. Before the fix, that silently succeeds and double-books them. After the fix, it's reported as failed and nothing moves.
The broader habit this reinforced: when you fix a bug in one place, go look for the other places that solve the same kind of problem, and check whether the fix you're about to write is actually just "make this one consistent with the rest." Six other endpoints had already answered this question correctly. I just needed to ask it of the seventh.