Bug preventing calendars.getAvailability()'s availabilityRules.buffer from working when startTime and endTime are an hour apart

[sm-fm]

Describe the bug
When I use nylas.calendars.getAvailability() to query one or multiple user's calendar availability where startTime and endTime are greater than an hour apart, the buffer works correctly. However, if I use the same method where startTime and endTime are just an hour apart, the durationMinutes is 60, and the buffer.before and buffer.after are 60, it does not work.

For example, I use getAvailability() to cache my user's calendar availability for 60 days. In this instance, the startTime is a timestamp for the next day from when I invoke getAvailability(). The endTime is 60 days from startTime ending at 7pm of that day ET. If my users have events on their calendar, I will not receive a time slot from Nylas for an hour before or after that event on the user's calendar. This is what I expect.

However, I'll check a specific time slot to ensure my user is still available before I actually schedule the appointment. I want to provide a 60 min buffer before and after this time slot, so I use the same method with the same configuration as discussed above. If a user has an event from 9am ET to 10am ET on their calendar when I do this check for 8am ET to 9am ET, I expect the time slot for 8-9 to not be returned since the user already has event scheduled for 9am. However, I am receiving that time slot back (8am to 9am), indicating that the user is still available when in fact they are not. This is the bug.

Below is how I'm actually invoking getAvailability() for your reference:

const response = await nylas.calendars.getAvailability({
        requestBody: {
          startTime: meetingStartTime,
          endTime: meetingEndTime,
          durationMinutes: 60,
          participants: emails,
          availabilityRules: {
            buffer: {
              // Should provide a 60 min buffer before and after existing meetings on the users' calendars
              before: 60,
              after: 60,
            },
          },
        },
      })

      return response.data.timeSlots

I use this same method when I'm grabbing a user's calendar availability for 60 days and for a single hour window on a specific date.

To Reproduce
Some steps involved to reproduce the bug and any code samples you can share.

// Helps us with reproducing the error :)

Using the configuration I have above for getAvailability(), try querying for an hour time slot when the user has an event right after it. Then try it when a user has an event for right before.

For example, say the user has an event from 10am to 11am already scheduled on their calendar. Pass in the startTime and endTime for 9am to 10am that same day. No time slot should be returned since we have the 60 minute buffer for after. However, you will see that time slot come back.

Next, try the same thing but for the time slot 11am to 12pm. The same behavior will happen.

Expected behavior
A clear and concise description of what you expected to happen.

When I use the buffer of 60 minutes before and after and query for a single hour window on a user's calendar, the time slot should be returned only if the user has nothing scheduled for an hour before and and hour after. For example, if I query for 9am to 10am, the user should not have anything on their calendar for 8am to 9am or anything in between or 10am to 11am or anything in between.

SDK Version:
Providing the SDK version can help with the reproduction of the issue and to know if a change could have broken something.

7.5.2

Additional context
Add any other context about the problem here.

[sm-fm]

@SubashPradhan any insight you could provide would be helpful.

[SubashPradhan]

Hey @sm-fm Thank you for reporting this issue, it looks like an issue with our API, on how we calculate availability. We have opened an internal ticket for this issue and will initiate investigation on the API side.

[sm-fm]

@SubashPradhan awesome -- thanks for the update. I'm assuming you'll close this issue once that fix has been deployed? We're currently manually creating the buffer for our application, so we'll need to remove that once the fix is deployed.

[SubashPradhan]

Sure thing @sm-fm, we will update you once we have fix ready.