feat: check guest availability when host reschedules a booking

[MrLawrenceKwan]

What does this PR do?

When a host reschedules a booking, this PR checks if any attendees (guests) are Cal.com users. If they are, their existing bookings are fetched as busy times and included in the available slots calculation — ensuring the host can only reschedule to times that work for both parties.

Problem

Currently, when a host reschedules, the system doesn't check the guest's availability. If the guest is a Cal.com user, this can result in scheduling conflicts.

Solution (minimal, focused changes)

1. UserRepository.findUsersByEmails() — Looks up Cal.com users by attendee emails
2. BookingRepository.findAcceptedBookingsByUserIdsOrEmails() — Fetches accepted bookings for those users within the date range
3. getUserAvailability — Accepts optional guestBusyTimes in initialData
4. slots/util.ts — Orchestrates the flow: when rescheduleUid is present, fetches guest busy times and passes them through

Design decisions

• Graceful degradation: If guest availability lookup fails, rescheduling still works (logged as warning)
• Only Cal.com users: Non-Cal.com guests are skipped (we cannot check their calendar)
• Excludes current booking: The booking being rescheduled is excluded from busy time calculation
• No UI changes: The existing reschedule UI automatically respects the filtered slots

Files changed (4 files, +122 lines, -0 lines)

• packages/features/users/repositories/UserRepository.ts
• packages/features/bookings/repositories/BookingRepository.ts
• packages/features/availability/lib/getUserAvailability.ts
• packages/trpc/server/routers/viewer/slots/util.ts

/claim #16378

Fixes #16378

[CLAassistant]

All committers have signed the CLA.

[graphite-app]

Graphite Automations

"Send notification to Community team when bounty PR opened" took an action on this PR • (02/15/26)

2 teammates were notified to this PR based on Keith Williams's automation.

[cubic-dev-ai]

1 issue found across 4 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/features/users/repositories/UserRepository.ts">

<violation number="1" location="packages/features/users/repositories/UserRepository.ts:289">
P2: findUsersByEmails ignores secondary emails and account status, so attendee lookups can miss valid users (secondary email) or include locked/unverified accounts in availability checks. This diverges from the established verified/secondary-email-aware lookup in the same repository and can skew reschedule availability.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: findUsersByEmails ignores secondary emails and account status, so attendee lookups can miss valid users (secondary email) or include locked/unverified accounts in availability checks. This diverges from the established verified/secondary-email-aware lookup in the same repository and can skew reschedule availability.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/features/users/repositories/UserRepository.ts, line 289:

<comment>findUsersByEmails ignores secondary emails and account status, so attendee lookups can miss valid users (secondary email) or include locked/unverified accounts in availability checks. This diverges from the established verified/secondary-email-aware lookup in the same repository and can skew reschedule availability.</comment>

<file context>
@@ -277,6 +277,26 @@ export class UserRepository {
+    const normalizedEmails = emails.map((e) => e.toLowerCase());
+    return this.prismaClient.user.findMany({
+      where: {
+        email: { in: normalizedEmails },
+      },
+      select: {
</file context>

[MrLawrenceKwan]

Thanks for the review! Regarding the findUsersByEmails observation:

This function intentionally does a simple primary email lookup for the reschedule guest availability check. The rationale:

1. Guest emails come from the booking record — these are the emails guests used when booking, which would match their primary Cal.com email in the vast majority of cases
2. False negatives are safe — if a guest's secondary email isn't matched, the reschedule simply won't check their availability (same as current behavior for non-Cal.com guests). The host can still reschedule.
3. Account status filtering — locked/unverified accounts are edge cases that don't meaningfully affect availability checks for rescheduling

That said, if maintainers prefer using the verified/secondary-email-aware lookup pattern, I'm happy to update this to use findManyByEmailsWithEmailVerificationSettings instead. Let me know!

[Ryukemeister]

hi there, thanks for your contribution. can you please add relevant e2e tests for the PR, also attaching a visual demo would be really helpful. thanks!