Online order scheduled over an existing scheduled order

Objective

• Understand why two inspections (1008593660 internal first, 1008594585 online second) ended up with the same inspector and inspection date while the original report described them as overlapping (“scheduled on top” of an existing order).
• Prevent recurrence if the root cause is a timing, sync, or confirm-time gap—not assume the online slot picker is broadly broken.
• Harden scheduling where appropriate so an online booking cannot commit the same inspector and time as an existing non-cancelled job, even under race or stale availability.

Background

• Production report: an online order was scheduled on top of an already scheduled order. Initial Slack context noted the two orders “were not the same day,” but follow-up on the inspections states the same inspector and inspection date were used and the inspector was already booked on the confirmed internal order when the online job was scheduled.

• 1008593660 was booked first, internally by a user.

  Spectora changelog:

  

• 1008594585 was booked second, online.

  Spectora Changelog:

  

• Repro attempt (same brand instance): Ryan recreated the scenario with no success—tried multiple inspectors including the one from the incident. In both attempts the online scheduler did not show any slots for the time of the internally booked inspection. That indicates GET /schedule/optimal-slots overlap filtering behaves correctly when the internal inspection is already in Attik at slot-load time.

• Code audit (likely incident class): Conflict prevention today is on the read path only (optimal-slots); POST /spectora/create-job and POST /inspection/book-job do not re-validate inspector availability at confirm. Plausible one-off causes for the original pair: Attik DB/sync lag after internal book, 5-minute cache(300) on optimal-slots, race between slot load and confirm, inspection/event queries that match start datetime only (not full interval overlap), or the two jobs not actually sharing the same datetime/endtime despite same calendar date.

• Decision needed: Treat as investigation-first (prod timestamps on both inspections) vs. immediate hardening (book-time conflict check). Confirm whether datetime/endtime truly overlap before building a large scheduler change.

• Slack: attik-talk thread

Scope

Backend

• Slot availability (working in repro): src/routes/schedule.ts (GET /optimal-slots, findAvailableSlots, TZDayjs interval overlap per inspector, cache(300)), src/util/functions/schedule/batchSlotOptimizingAlgo.ts, src/util/functions/slots/slotToHistory.ts, src/util/functions/calendar/inspectorIdMatching.ts.
• Booking confirm (no overlap check today): src/routes/spectora.ts → createSpectoraJob, src/routes/inspection.ts → POST /book-job.
• Calendar data loaded for slots: inspections (Inspection), Event (type Event and Block), vacations; cancelled inspections excluded.
• Investigation data: Compare datetime, endtime, _inspectorId, status, scheduledLocation, createdAt on 1008593660 and 1008594585 vs. Spectora changelog timing.
• Optional hardening (if investigation supports): shared book-time conflict validation; align inspection/event DB filters with block-style interval overlap; reduce or bypass slot cache on confirm path.

Frontend

• Online scheduler: src/app/scheduler/slots/SlotsStep.tsx (calls schedule/optimal-slots with excludeOverlapping), src/app/scheduler/summary/BookingJobLoader.tsx (posts spectora/create-job or inspection/book-job).
• Working hold: src/util/functions/quote/manageWorkingHold.ts (Block events—not transactional with book).
• Internal scheduling (related patterns): src/components/scheduling/NewSchedulingForm.tsx, DispatchSection.tsx also consume optimal-slots.

References

• Inspections: 1008593660, 1008594585
• Slack: attik-talk thread
• Backend: src/routes/schedule.ts, src/routes/spectora.ts, src/routes/inspection.ts
• Frontend: src/app/scheduler/slots/SlotsStep.tsx, src/app/scheduler/summary/BookingJobLoader.tsx