[booking][P2 MEDIUM] No no-show automation: SCHEDULED appointments never auto-close on absent attendance, no NO_SHOW state, no money/credit reconciliation (revives #471)

[teetangh]

Summary

There is no no-show automation in the product. A consultee who books a paid/approved session and never attends leaves the appointment in a SCHEDULED state forever — no automatic NO_SHOW/COMPLETED-with-marker transition, no consultant/consultee flag, no earned/credit reconciliation, no follow-up workflow.

The prior tracking issue #471 ("No-show detection and handling system") is closed without a shipping implementation; this re-opens the gap as a concrete requirement set.

Current state (verified)

• AppointmentStatus enum (prisma/schema.prisma:3677-3688): PENDING, APPROVED, APPROVED_PENDING_PAYMENT, SCHEDULED, COMPLETED, REJECTED, CANCELLED, EXPIRED — no NO_SHOW state.
• Stream/call-presence code (lib/stream/call-presence.ts, lib/stream/session-handlers.ts, lib/stream/webhook-events.ts) has no-show signals (connection state, attendance metadata) but nothing closes the booking or reconciles it.
• No cron/job sweeps SCHEDULED appointments against session attendance to mark no-shows.

The gap

1. No state machine edge for no-show: a session that starts and ends with the consultee absent is indistinguishable from a normal completed session at the data layer.
2. No auto-close: no sweep that marks an elapsed SCHEDULED appointment as no-show when attendance is absent (and with recording presence, a no-show, or a served-vs-not determination).
3. No money/credit reconciliation: depends on the refund/credit design — whether a no-show refunds, forfeits, or consumes the credit; must be decided and wired (see [Big Pickle][finance] Overall Verdict on the Financial Subsystem (HLD + LLD) — 40-issue backlog, scheduler concurrency gap, HLD drift #1421 finance verdict, refund-hardening issues).
4. No consultant-facing surface: consultant dashboard has no "did they show?" confirm/flag, so no-show data never enters the loop (matches [RESILIENCE] No-show detection and handling system #471 intent).

Recommended approach

• Decide the money model for no-show (tied to refund/cancellation policy work).
• Add a NO_SHOW appointment state and a sweep (mirroring expire-reschedule-proposals / expire-stale-requests cron patterns) that moves elapsed SCHEDULED appointments to a no-show terminal state when session attendance is empty.
• Surface a consultant "confirm attended / mark no-show" action in the consultant UI (dashboard), defaulted to auto on elapsed-session + no presence.
• Denormalize any attendance/no-show marker per the schema directive (typed field, not JSON).

Files

• prisma/schema.prisma:3677-3688 — AppointmentStatus (no NO_SHOW)
• lib/stream/call-presence.ts, lib/stream/session-handlers.ts, lib/stream/webhook-events.ts — attendance/presence signals (raw, unconsumed for no-show)
• jobs/appointments/*, scripts/appointments/* — existing cron patterns to mirror

Related

• [RESILIENCE] No-show detection and handling system #471 (prior closed no-show tracking)
• [Big Pickle][finance] Overall Verdict on the Financial Subsystem (HLD + LLD) — 40-issue backlog, scheduler concurrency gap, HLD drift #1421 (finance verdict — no-show money model)
• Refund-hardening issues (no-show ↔ refund/credit interplay)
• [Big Pickle][booking] Overall Verdict on the Booking Subsystem (HLD + LLD) — P0-P3 indexed backlog, backend core + UI (B2C + B2B), 10 new findings #1433 (booking verdict)

[teetangh]

Cross-linked from umbrella #1503 ([Big Pickle][booking] Booking Lifecycle & Event Planning Verdict) — full summary, sequencing (money-first → availability → negotiation → post-MVP), and the shared cross-cutting rules (booking-money-boundary, booking-concurrency/docrine, cron sweep shape, schema directive).

[teetangh]

Verification: PARTLY-FIXED — rebanded launch: post-mvp, keeping open for the remainder

Verified against dev at 1f32ba90a. Two of this issue's premises are false against the current code, and a real remainder survives.

Already built: consultant no-show detection, auto-cancel and auto-refund. scripts/appointments/detect-consultant-no-shows.ts is a complete hourly job. It runs under a fail-closed cron lock at :80-85, selects candidates whose slots all ended past a 120-minute grace window and that actually held a MeetingSession (:51, :91-115), corroborates our attendance rows against Stream before moving money (:573-583, with a contradicted counter for lost webhook deliveries), claims the booking with a compare-and-set at :418-433, refunds through the booking front door refundBookingPayment, and notifies both parties. Sessions nobody attended are raised as support tickets rather than silently decided (detectBothAbsent, :400-412).

Already built: elapsed sessions do close. The claim that a booking "leaves the appointment in a SCHEDULED state forever" is not true. scripts/appointments/auto-complete-appointments.ts:243-259 sweeps every APPROVED or SCHEDULED consultation whose slots all ended more than COMPLETION_BUFFER_HOURS = 1 ago and moves it to COMPLETED under a compare-and-set at :294-299, hourly.

Important caveat on the consultant path. Those two jobs are currently mis-ordered, so the consultant no-show refund never actually fires in production: auto-complete claims the row at end plus one hour, while the detector only becomes eligible to look at it at end plus two hours, and COMPLETED is not in the detector's candidate filter. That is filed separately as #1504 (priority: critical, launch: pre-mvp) and a fix is being prepared; it is not part of this issue's scope.

What genuinely remains, and why this issue stays open.

1. There is no consultee-no-show rule. The detector is scoped to consultant absence only; a paid consultee who simply never joins is indistinguishable from an attended session at the data layer.
2. There is no NO_SHOW member on AppointmentStatus (prisma/schema.prisma:3677-3688), and no NO_SHOW slot status either. scripts/appointments/detect-consultant-no-shows.ts:418 records the workaround explicitly: "no NO_SHOW slot status exists — schema frozen, [RESILIENCE] No-show detection and handling system #471 — CANCELLED is the closest".
3. There is no consultant-facing "did they attend" confirm or flag, so human attendance signal never enters the loop.
4. The money model for a consultee no-show is undecided: forfeit, tier refund, or credit consumption. That decision gates items 1 and 2.

Rebanded launch: post-mvp: the consultant side, which is the side that moves money, is already automated, and the remainder is a product decision plus a schema addition rather than something a paying customer hits in the first weeks.

[teetangh]

Verdict 2026-09-05 (booking closure pass, dev 9dc665a). Confirms the partial verdict with two corrections. NO_SHOW does exist at schema.prisma:625 and CONSULTANT_NO_SHOW at :695, but on the support enums, not as a booking status, so the substance holds. Second, claimConsultantNoShow (scripts/appointments/detect-consultant-no-shows.ts:418-433) writes Consultation.status with a bare updateMany instead of transitionConsultationRequest, so a consultant-no-show cancellation writes no BookingStatusHistory row — the same class of defect #1383 fixes on the routes. That conversion is being made in the booking closure train's cron PR after #1505 merges (Part of #1493). The four remainders (consultee-no-show rule, a NO_SHOW status member gated on the reset, consultant attendance confirm, the money model) stay post-MVP and need one product decision first: forfeit, tiered refund, or credit consumption for a consultee no-show.

[teetangh]

Follow-up from the closure train (2026-09-06): #1516 routes claimConsultantNoShow's consultation write through transitionConsultationRequest inside one transaction, so a consultant no-show cancel now writes its BookingStatusHistory row. Still outside the CAS helpers in that function: the slot sweep (tx.slotOfAppointment.updateMany → CANCELLED), which should become transitionSlotCompletion to CANCELLED with deletedAt, the shape #1383 gave the cancel route. Small, no schema; belongs with the post-MVP remainder tracked here.