fix: handle collective multiple host on destinationCalendar

Hi there 👋

🌥️ Tech	🌥️ Feat
9 high, 6 medium, 6 low	1 ok, 2 issues, 1 mitigated

This MR converts CalendarEvent.destinationCalendar into an array (DestinationCalendar[] | null) with a fallback to a single main destination calendar, aiming to fix #7754 so collective events with multiple hosts create events on each host's chosen calendar. The core type conversion is consistent (Calendar.d.ts, CalendarEventClass, builder), and most booking handlers, webhooks, and email templates were migrated to build arrays correctly. The positive areas: the payment webhooks and organisation-of-handlers construct arrays with correct [] fallbacks, and BrokenIntegrationEmail handles the array/empty cases safely for common integration types.

However, several blocking regressions and gaps prevent the MR from fully achieving its stated goal:

• Crash on empty/null destinationCalendar: EventManager.create lost its optional chaining and throws a TypeError instead of gracefully falling back (Google Meet + no Google calendar scenario returns a 500).
• Field-loss regressions: bookings created through the non-credentialId path lose externalCalendarId, video references lose credentialId, and updateLocation's returned references always carry undefined for both, breaking downstream reschedule/cancel/update flows.
• Collective handling is incomplete/inconsistent: collective host calendars are silently dropped when the organizer has no destinationCalendar; the fallback iterating organizer's credentials can create duplicate/wrong-calendar events for a host whose destination lacks a credentialId; and Lark/Office365/CalDAV still take only the first array element and ignore per-credential destinations, so non-Google providers do not honor multiple hosts.
• Broken Google update/delete fallback: a self-referential find can never match, causing updates to fail and deletes to target the host's primary calendar.
• Contract drift: createEvent now mandates a non-optional credentialId parameter that most implements Calendar services don't implement or consume.
• Unrelated regression: the org-creation handler inverts the slug/requestedSlug billing logic.
• Coverage gaps: paid collective events in payment webhooks still only get the organizer's calendar, and the e2e tests don't exercise the collective multi-host path.

Recommend addressing the blocking items (crash, reference-field losses, Google fallback, consistent cross-provider selection, and the org-slug inversion) before merging.

---

These might need a close look

• 🔴 packages/core/EventManager.ts (L119)
  Crash when destinationCalendar is empty/null: const [mainHostDestinationCalendar] = evt.destinationCalendar ?? []; followed by mainHostDestinationCalendar.integration throws a TypeError when the array is null or empty (now produced by callers). The pre-PR evt.destinationCalendar?.integration was safe. Guard with mainHostDestinationCalendar?.integration !== "google_calendar".
• 🔴 packages/core/EventManager.ts (L380)
  Booking references lose externalCalendarId on the non-credentialId path: externalCalendarId is derived solely from result.externalId, which is only populated when createEvent is called with the explicit destination.externalId argument. The non-credentialId branch, empty-array fallback, and other_calendar path call createEvent without externalId, so persisted BookingReference.externalCalendarId becomes undefined. Later updateAllCalendarEvents and handleCancelBooking rely on it to locate the event. Pass destination.externalId in these calls or fall back to it when building the reference.
• 🔴 packages/core/EventManager.ts (L208)
  updateLocation's referencesToCreate always emit undefined externalCalendarId/credentialId: updateAllCalendarEvents's updateEvent does not return externalId/credentialId, and the pre-PR code read these from evt.destinationCalendar. Any flow writing these references back will persist empty values, breaking later updates/deletes. Either have updateEvent return these, or pull them from the event's destination calendar.
• 🔴 packages/core/EventManager.ts (L376)
  Potential duplicate events for collective bookings: the else branch iterates the organizer's calendarCredentials for every array entry lacking a credentialId. For a COLLECTIVE booking with one entry per host, any host destination without credentialId fires the branch using the organizer's credentials, creating duplicate events on the organizer's calendar and events for a different host's destination. Scope the fallback so it only applies to the main/organizer destination.
• 🔴 packages/app-store/googlecalendar/lib/CalendarService.ts (L256)
  Google updateEvent/deleteEvent fallback can never match the destination calendar (regression): event.destinationCalendar?.find((cal) => cal.externalId === externalCalendarId)?.externalId is self-referential — when externalCalendarId is falsy (the else branch), the predicate compares against null/undefined and never matches, yielding selectedCalendar === undefined. Updates fail against the API, and deleteEvent then falls back to "primary" (deleting from the host's primary calendar instead of the destination). Mirror createEvent (match by credentialId) or restore a first-element/externalId fallback.
• 🔴 packages/app-store/larkcalendar/lib/CalendarService.ts (L128)
  Inconsistent destination-calendar selection across providers for collective events: only Google's createEvent matches by credentialId; Lark (createEvent/createAttendees/updateEvent/deleteEvent), Office365 (line 71) and the CalDAV base service (line 156-159) all take the first element (const [mainHostDestinationCalendar] = event.destinationCalendar ?? []) and ignore the per-credential externalId/credentialId passed by EventManager. This routes a host's event to the first host's calendar id (possibly a different provider), which is the exact scenario this MR is meant to fix.
• 🔴 packages/features/bookings/lib/handleNewBooking.ts (L1078)
  Collective host calendars are silently dropped when the organizer has no destinationCalendar: evt.destinationCalendar is initialized to null, and the collective merge evt.destinationCalendar?.push(...teamDestinationCalendars) is a no-op due to optional chaining — discarding all other hosts' calendars. Build the array unconditionally (e.g. [...(evt.destinationCalendar ?? []), ...teamDestinationCalendars]) and/or initialize the fallback to [].
• 🔴 packages/trpc/server/routers/viewer/organizations/create.handler.ts (L151)
  ORG-4: slug conditional logic inverted in org creation (regression unrelated to destinationCalendar): the slug spread was flipped from ...(!IS_TEAM_BILLING_ENABLED && { slug }) to ...(IS_TEAM_BILLING_ENABLED ? { slug } : {}). When billing is disabled (default self-host), the org slug is no longer persisted at creation, breaking org subdomain/URL handling. Restore the original !IS_TEAM_BILLING_ENABLED && { slug } semantics.
• 🔴 packages/types/Calendar.d.ts (L218)
  Calendar.createEvent now mandates a non-optional credentialId: number param, but only GoogleCalendarService was updated to receive/use it. Every other implements Calendar service still declares createEvent(event) and ignores credentialId (TypeScript accepts it due to parameter assignability). The hardened contract implies every provider selects its destination by credentialId, yet only Google honors it — for collective multi-host events the additional hosts' chosen calendars are not honored by other providers. Make the param optional or implement/consume credentialId in the remaining services.

Worth checking

• 🟡 packages/core/EventManager.ts (L170)
  Video references now lose credentialId: credentialId: isCalendarType ? result.credentialId : undefined always yields undefined for non-calendar (video) results. Pre-PR code preserved result.credentialId for video references (used by seat/later flows matching on credentialId). Keep result.credentialId for the non-calendar case.
• 🟡 packages/app-store/larkcalendar/lib/CalendarService.ts (L128)
  Empty-array error handling is inconsistent across the four services: Google falls back to "primary", Office365 to "/me/calendar", CalDAV creates on all listed calendars, and Lark throws Error("no calendar id"). Confirm this divergence is intentional or align Lark with the graceful fallback so a user without a configured destination calendar gets a consistent experience.
• 🟡 packages/features/bookings/lib/handleNewBooking.ts (L1063)
  Inconsistent destinationCalendar fallback: null vs [] — handleNewBooking falls back to null while every other handler in this PR falls back to [], producing inconsistent webhook payload shapes (BOOKING_CREATED/BOOKING_REQUESTED emit null; BOOKING_REJECTED/CANCELLED emit []). Standardize on [] and update the e2e expectations.
• 🟡 packages/features/bookings/lib/handleNewBooking.ts (L990)
  Collective host-collection assumes users[0] is the organizer: team calendars are collected from users.slice(1), but users preserves the hosts array order and the organizer may not be first. This either skips a real host's calendar or duplicates the organizer's. Derive the organizer index explicitly (e.g. compare user.id === organizerUser.id) instead of relying on slice(1).
• 🟡 apps/web/playwright/webhook.e2e.ts (L246)
  Webhook e2e does not exercise the multi-host scenario: none of the booking webhook tests create a collective event with multiple hosts, so the teamDestinationCalendars push path is never exercised and the failure in handleNewBooking (dropped host calendars) would go undetected by CI. Add a collective multi-host test asserting a populated destinationCalendar array with each host's calendar.
• 🟡 packages/features/ee/payments/api/webhook.ts (L229)
  Collective paid events don't get multi-host destination calendars: handlePaymentSuccess (and getBooking/handleSetupSuccess at ~119, and paypal-webhook.ts ~152) build the array from only the organizer's single calendar. For a paid COLLECTIVE event created in PENDING and confirmed via these webhooks, only the organizer's calendar receives the event — the other hosts are skipped, which is the bug (#7754) this PR targets. Aggregate host destination calendars for collective bookings, or document as out of scope.

Small things (take or leave)

• 🔵 packages/core/EventManager.ts (L599)
  Removed error logging in updateAllCalendarEvents catch: the catch block computes message but the pre-PR console.error(message) was removed, leaving message unused and swallowing the error detail. Restore the log or surface the error.
• 🔵 packages/features/bookings/lib/handleNewBooking.ts (L688)
  isTeamEventType recomputed with string-array membership instead of the enum: ["COLLECTIVE","ROUND_ROBIN"].includes(eventType.schedulingType) loses type safety and diverges from the project pattern (SchedulingType.ROUND_ROBIN still used at ~856). Prefer enum comparisons.
• 🔵 packages/features/ee/payments/api/paypal-webhook.ts (L152)
  Minor consistency: webhook.ts extracts the fallback into a named variable then wraps it, while paypal-webhook.ts inlines a nested ternary in the object literal. Functionally equivalent; consider aligning the styles for readability.
• 🔵 packages/emails/src/templates/BrokenIntegrationEmail.tsx (L89)
  Optional chaining does not protect .integration.split("_"): mainHostDestinationCalendar?.integration.split("_") only guards the calendar object, not integration. A missing/empty integration field would throw a TypeError and crash the email render inside the organizer's email-send path. Use mainHostDestinationCalendar?.integration?.split("_") (the ?. is redundant given the surrounding ternary).
• 🔵 packages/emails/src/templates/BrokenIntegrationEmail.tsx (L94)
  Possible "undefined" calendar name: calendarCap[0] + " " + calendarCap[1] assumes every calendar integration contains _ (xxx_calendar). All current integrations match, but a future non-conforming type renders e.g. "Google undefined". Add a calendarCap.length > 1 ? calendarCap.join(" ") : calendarCap[0] guard.
• 🔵 packages/emails/src/templates/BrokenIntegrationEmail.tsx (L87)
  Broken-calendar email only reflects the first host's calendar: for collective events the template reads the first array element, so if a non-first host's calendar integration is broken, the email shows the main host's calendar name — potentially misleading which calendar to re-install. This mirrors the intentional main-host fallback but should be confirmed as intended UX.

---

✅ Feature-level checklist

Looks good

• ✅ Convert destinationCalendar on CalendarEvent to be an array.
  The type is widened to DestinationCalendar[] | null consistently in Calendar.d.ts (line 171) and the CalendarEventClass (class.ts line 27), and construction sites build arrays (single-element fallback or []/null).

Not there yet

• ❌ Patch and fix every sentence of code using evt.destinationCalendar so it supports the new array type.
  Several paths still fail on the array/empty/null shape or regress: EventManager.create crashes on null/[] (line 119); Google updateEvent/deleteEvent fallback is broken (line 256/317); externalCalendarId is lost on the non-credentialId path (line 380); video references lose credentialId (line 170); updateLocation writes undefined references (line 208); and the createEvent contract now expects a credentialId most implementations don't support (Calendar.d.ts line 218).
• ❌ Collective events with multiple hosts (fixes #7754): every host with a calendar app receives proper calendar events.
  Multiple blockers: collective host calendars are dropped when the organizer has no destinationCalendar (handleNewBooking line 1078); the fallback can create duplicate/wrong-calendar events for entries lacking credentialId (EventManager line 376); Lark/Office365/CalDAV only take the first element and ignore per-credential destinations (lark line 128); paid collective events only get the organizer's calendar in payment webhooks (webhook line 229); and e2e tests don't cover the multi-host scenario.

Partially covered

• ⚠️ Fallback to a single main destinationCalendar while supporting multiple so the host is invited correctly.
  The single-main fallback works in most handlers, but it is not robust: the empty/null fallback crashes in EventManager.create, and the Google fallbacks for update/delete resolve to undefined/primary. The multi-entry support is partial — see the collective-specific findings.