[booking][P1 HIGH] Default booking length (1h) vs authored block (2h): heatmap/dialog show fragmented 1-hour slots, never the combined 2h session

[teetangh]

Summary

When a consultant authors availability as a block longer than the default booking length — e.g. a 2-hour block 7:00 PM – 9:00 PM with no explicit per-session length — the booking heatmap/dialog renders it as fragmented 1-hour windows (7:00–8:00, 7:30–8:30, 8:00–9:00) and never offers the authored combined 2-hour session. The availability calendar, by contrast, shows the single 7–9 block.

Evidence

• app/explore/experts/[consultantId]/components/ConsultationPricingToggle.tsx:92:

  const selectedDuration = activePlanOption?.durationInHours ?? 1;   // default 1 hour
  

  When the plan/tier has no duration (or the default is taken), the booking generator segments the availability in 1-hour windows.
• utils/timeSlotsProcessing.ts:902-988 (breakDownSlotsPreservingStatus): for durationInHours = 1, a 7–9 block is sliced into 7–8, 7:30–8:30, 8–9 by the 30-minute sliding window.
• The server emits 30-minute atoms for every available block (app/api/slots/availability-with-allocation/[consultantId]/route.ts:672-680 → processAvailabilitySlots default 0.5), so a 2-hour block is 4 atoms, but the client re-segments them at the selected/default duration.

Why it matters

• The consultant's intent ("I offer a 2-hour slot") is not honoured: the customer is offered 1-hour windows against a 2-hour availability block.
• The booking surface and the availability surface disagree on what is bookable — the exact inversion of the user report "pricing toggle shows empty on 2h" (that symptom is the segmentation fallback gap; this one is the default-length default).
• Silent mismatch between how consultants author availability and how it is booked is a launch blocker.

Suggested fix direction

• Make the default booking length derive from the authored availability block (or the consultation option's own durationInHours), so a 2-hour authored block is booked as a 2-hour session by default, not fragmented into 1-hour windows.
• Surface the effective session length to the consultant during availability authoring (onboarding + settings) so they can see "this block will be booked as a single X-session" and never author a block that silently fragments.
• Ensure the heatmap/dialog and the pricing toggle use the SAME effective duration default so both show the combined session when the user hasn't toggled.

Related

• Pairs with the pricing-toggle segmentation issue (same breakDownSlotsPreservingStatus path) — this one is the default-duration half, that one is the no-fallback-when-duration-explicitly-selected half.
• Open PR fix(explore): expert booking calendar — viewport-fit dialog, nav z-stack, per-day availability dots #1229 (DRAFT) touches the explore surfaces but only for responsiveness, not this default-length logic.

Terms

default duration · booking length · fragmentation · authored block · session length · heatmap · dialog

[teetangh]

Relates to #1415 (same breakDownSlotsPreservingStatus path — this is the default-duration half, #1415 is the no-fallback half) and #1416 (merge tolerance).

[teetangh]

False premise — verified 2026-09-05 against dev (9dc665a), closing

The quoted line is live, but the ?? 1 at app/explore/experts/[consultantId]/components/ConsultationPricingToggle.tsx:92 is dead code. activeConsultationOption is seeded from the consultant's real plans through formatPricingOptions (ExpertPricing.tsx:72-140), and ConsultationPlan.durationInHours is non-nullable with a default (prisma/schema.prisma:3440), so the toggle's duration is always the selected plan's duration and never an invented 1-hour default.

The premise that an availability block expresses an intended session length inverts the model. Availability answers "when is the consultant free"; the plan answers "how long is a session". A consultant who sells a 2-hour session creates a 2-hour plan, and the toggle then offers 7:00–9:00. That is pinned by __tests__/booking-algorithm/availability-window-merge.test.ts:240-245, which feeds a 2-hour block spanning two availability rows into breakDownSlotsPreservingStatus(..., 2, ...) and gets exactly one 2-hour window. Offering 1-hour windows inside a 2-hour free block for a 1-hour plan is therefore correct, and it is the same split Cal.com uses for its multiple-duration event types.

If the product ever wants "authoring a 2-hour block creates a 2-hour offer", that is a new feature (derive plans from availability), not this bug, and deserves its own issue.