Admissions Consulting CRM

Why it was hard

Two opposite symptoms were mixed on the same matching screen. Duplicates that should have been blocked got through, and valid matches were blocked by locks on past time slots. The code that decides whether a slot is held was also scattered across several places.

How I traced it

1. 1. What does the available-time logic count as holding a slot?

   Only consultations in scheduled, in progress or completed status.

2. 2. What does the booking side count as holding?

   Only bookings awaiting payment or confirmed. The paid-but-not-yet-matched state wasn't counted as holding on either side.

3. 3. Is it checked when a match is confirmed?

   The confirm step had no conflict check at all.

4. 4. How do I show why it got stuck in production?

   I built a read-only diagnostic command that prints the blocking reason step by step, and found the cause without changing any data.

Root cause

The list of holding statuses was missing the statuses from paid through awaiting match, and confirming a match didn't check for conflicts.

Fix

I defined paid through in progress as holding statuses. When a match is confirmed, it checks whether it overlaps, buffer time before and after included, with that consultant's holding consultations and live bookings. If it overlaps, it's rejected as 'time already booked'.

confirm_matching(consultation, consultant, time):
    save()                                  # no conflict check

HOLDING = {PAID, SURVEY, AWAITING_MATCH, MATCHED, APPROVED, SCHEDULED, IN_PROGRESS}
conflict = any(other.consultant == consultant
               and other.status in HOLDING
               and overlaps_with_buffer(time, other)
               and other != consultation)
        or any(live booking overlaps, excluding own booking)
if conflict: raise "time already booked"

Why it was hard

The symptoms all looked alike ('the booking info is off'), but there were 4 causes. The time zone bug was especially hard: the value stayed the same and only its label changed to UTC, so the stored value alone didn't look wrong.

How I traced it

1. 1. Why do products with a changed duration overlap?

   It computed the held range using the old duration saved on the existing booking (for example, 30 minutes).

2. 2. Why do consultations for canceled orders come back?

   On re-sync, the 'has been paid' condition was true, and deleted consultations are hidden from the default query, so it decided 'the consultation is missing' and created it again.

3. 3. Why does another option's time get in?

   The first matching pass compared only the product code. The option filter was only in the second, fallback pass, so if the first pass picked a booking for another option, the option check never ran.

4. 4. Why are payment times off by 9 hours?

   After parsing a time with '+09:00', it only relabeled it as UTC. 09:22 Korea time became 09:22 UTC, which is 18:22 Korea time.

Root cause

The payment time parser didn't convert values that carried a time zone. It only relabeled them as UTC. This payment time is used for date filters, sorting and the payment date in notification text, so payments after 3 p.m. Korea time looked like next-day payments.

Fix

Only values without a time zone are labeled UTC. Values with a time zone are converted to UTC. Canceled orders never create a consultation, paid or not. Product and option filters apply at every matching pass, and the held range uses the longer of the saved duration and the product's current duration.

return parse(s).replace(tz=UTC)      # 09:22+09:00 -> 09:22Z (= 18:22 KST)

p = parse(s)
return p.replace(tz=UTC) if is_naive(p) else p.astimezone(UTC)

effectively_paid = not cancelled and (now_paid or paid_at)
busy_minutes = max(saved_duration, current_product_duration)