[CAL-3848] Booking of fixed duration occupy extra time even with all buffer times off and select duration off for booker

[qualiky]

Issue Summary

I have only one event type called appointment which is of 60 minute duration. I have the following settings configured for the event:

• no buffer before and after,
• time slot intervals of 60 minutes,
• minimum notice 0 days,
• Limit booking frequency off,
• Limit booking only first slot off,
• Limit total booking duration off,
• Limit future bookings off,
• Offset start times off

If I make an appointment, for example, 1PM-2PM, the cal's public page calendar is blocked off from 1PM - 2:45PM and my next available slots are 3:45-4:45, 4:45-5:45 etc, when in reality it should have been 2-3, 3-4, 4-5 and so on.

Steps to Reproduce

1. I go to my own public page and make an appointment for 1PM-2PM on behalf of a customer, for instance
2. I enter my details and the appointment is confirmed (my time zone is Asia/Katmandu, so both my customer and me are in same time zone)
3. I close the tab, open my public page in another incognito tab
4. My time is now only available from 2:45PM-3:45PM, 3:45PM-4:45PM, and so on.

It would be expected to block 1-2PM time, but it blocks 1-2:45PM. My booking list item in booking tab shows the appointment to be from 1-2PM, but the calendar in my public page shows 1-2:45PM blocked.

Better explained in this image: https://imgur.com/a/2wq6Vpe

Actual Results

• It's booking 1-2:45PM instead of 1-2PM, and my next slot available should be 2PM since I have no lead time or buffer time.

Expected Results

• It would be expected to be blocked from 1-2PM, with 2PM being the next available slot.

Technical details

• Cal.com instance on cloud: v.4.1.5-h[-1fd7b61 (https://github.com/calcom/cal.com/commit/1fd7b617eae9213a66093b0d9d4c9933d1872090)
• macOS Sonoma 14.5,
• Chrome Version 125.0.6422.113 (Official Build) (arm64)
• My app.cal.com dashboard and my public page booking are made from the same device, no VPN or proxy used, time zone +05:45 Asia/Katmandu

Evidence

Screen recording of the bug: https://drive.google.com/file/d/1H6VRIKuyqL3it5tuXJGXFbYT5cffZbRp/view?usp=sharing

How the actual event is in bookings link for 11am-12pm: https://drive.google.com/file/d/1GqR_eSgpVUdsd5gooNkXyDwqcQ1BJcOG/view?usp=sharing

How the cal.com public page calendar is blocked from 11am-12:45pm: https://drive.google.com/file/d/1tHRKBKkTxW2gLK2mpQSE9gfDjcJ0AiEn/view?usp=sharing

Settings of the booking: https://drive.google.com/file/d/1o0JfPlG5p5EZpDWvZfF-Zz-8hlwrxlt2/view?usp=sharing

(I apologize if I missed out on any detail and if I am truly dumb, I just can't seem to solve this. Made an alt account and had the same issue, the imgur screenshot above is from the alt account).

_CAL-3848

[dosubot[bot]]

Hey there, @qualiky! 👋 I'm here to help you with any bugs, questions, or becoming a contributor.

The issue you're experiencing with the calendar blocking extra time for a 60-minute appointment is likely due to the offsetStart parameter. This parameter introduces a delay between the end of one appointment and the start of the next available slot. Even though you have set "Offset start times off," there might still be an underlying issue with how this parameter is being applied.

In the buildSlots function, the offsetStart parameter is used to calculate the available slots. If there is an offset of 45 minutes, the next available slot after a 60-minute appointment starting at 1 PM would be at 2:45 PM. This is consistent with the behavior you're observing.

Here is a relevant snippet from the buildSlots function:

function buildSlots({
  startOfInviteeDay,
  computedLocalAvailability,
  frequency,
  eventLength,
  offsetStart = 0,
  startDate,
  organizerTimeZone,
  inviteeTimeZone,
}: {
  computedLocalAvailability: TimeFrame[];
  startOfInviteeDay: Dayjs;
  startDate: Dayjs;
  frequency: number;
  eventLength: number;
  offsetStart?: number;
  organizerTimeZone: string;
  inviteeTimeZone: string;
}) {
  // ... other code ...

  for (const [boundaryStart, boundaryEnd] of ranges) {
    for (
      let slotStart = boundaryStart + offsetStart;
      slotStart < boundaryEnd;
      slotStart += offsetStart + frequency
    ) {
      computedLocalAvailability.forEach((item) => {
        if (slotStart < item.startTime || slotStart > item.endTime + 1 - eventLength) {
          return;
        }
        slotsTimeFrameAvailable[slotStart.toString()] = {
          userIds: (slotsTimeFrameAvailable[slotStart]?.userIds || []).concat(item.userIds || []),
          startTime: slotStart,
          endTime: slotStart + eventLength,
        };
      });
    }
  }

  // ... other code ...
}

To address this issue, you should verify that the offsetStart parameter is indeed set to 0 and not being overridden elsewhere in the code. Additionally, you can add logging to the buildSlots function to debug the values of offsetStart and other relevant parameters during slot calculation.

For further debugging, you can check the following:

1. Ensure that the offsetStart parameter is correctly set to 0 in all relevant parts of the code.
2. Add logging to track the values of offsetStart, frequency, and eventLength during the slot calculation process.
3. Review any recent changes or updates in the buildSlots function or related scheduling logic that might have introduced this issue ^[1][2].

By following these steps, you should be able to identify and resolve the issue with the extra time being blocked for your appointments.

To continue talking to Dosu, mention @dosu.

[milospuac]

@emrysal