Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sm-fm opened this issue Oct 16, 2024 · 0 comments
Labels

Comments

@sm-fm
Copy link

sm-fm commented Oct 16, 2024

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 sm-fm added the bug label Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant