Fixes: https://github.com/calcom/cal.com/issues/12297
Fixes https://github.com/calcom/cal.com/issues/11234
- Displaying error message and X-Vercel-Id( Unique Request Id ) to user on book event form
- Improve error logging
- Add Error codes
Few things to discuss
1) How to handle calendar integration failures ?
Currently if for example google integration is broken and someone is trying to book that person then we log the error but don't inform the user that the google calendar is broken and the meeting goes through.
Should I throw error when integration is broken ?
<img width="758" alt="Screenshot 2023-11-12 at 12 52 36 AM" src="https://github.com/calcom/cal.com/assets/53316345/c4d921c4-9c8a-4b9b-82a2-bbe0fdbcb3d4">
2) How to handle conferencing app failures?
We just default to Cal Video as location if we are unable to generated conferencing url and log the error and not inform the user(organizer).
## What does this PR do?
Fixes that it can happen that Round Robin host is booked outside of availability.
I found and fixed the following two scenarios where this can happen:
- when host has a date override
- when host is available for only a part the event time (for example, booking time 9:00-11:00 and user is only available between 10:00-11:00)
Fixes#10315Fixes#11690
It also fixes that it can happen that round robin doesn't correctly pick the luck user (least recently booked). This happened when a user was an attendee of a booking before, then we always compared this booking and never the actual last booking of this user.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How should this be tested?
#### Booked outside of availability:
1.
- Create Round Robin event and assign user1 and user2 as round robin hosts
- event duration: 120 minutes
- user 1 availability:
- Monday to Friday 9:00-17:00
- user2 availability:
- Monday to Friday 10:00-17:00
- Book event at a 9:00 slot -> check if i user1 is booked
- Book event again at a 9:00 slot -> check if user1 is booked again (user2 is not available at that time)
2.
- Change availability of user2
- Mark Monday as unavailable
- Add date override on any day this month
- Book any Monday this month -> see that user 1 is booked
- Again Book any Monday this month -> see that user 1 is booked again
#### Wrong lucky user
- Book event and add user1's email as the attendee email address
- Book several slots where both users should be available, and see that it alternates between user1 and user2 (before it ended up always booking user1)
## Mandatory Tasks
- [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.
## What does this PR do?
- Adds AB tests middleware that redirects users to the app-dir pages with probability that is defined by env var
<!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -->
Fixes # (issue)
<!-- Please provide a loom video for visual changes to speed up reviews
Loom Video: https://www.loom.com/
-->
## Requirement/Documentation
<!-- Please provide all documents that are important to understand the reason of that PR. -->
This PR requires new env variables:
`APP_ROUTER_EVENT_TYPES_ENABLED` - boolean that defines if app dir event-types page redirect is enabled
`AB_TEST_BUCKET_PROBABILITY` - number [0, 100] that defines the percentage of users getting redirected to the app dir pages
## Type of change
<!-- Please delete bullets that are not relevant. -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] Chore (refactoring code, technical debt, workflow improvements)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
## How should this be tested?
<!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests -->
Does not requires testing, implements middleware as a dead code
## Mandatory Tasks
- [x] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.