What does this PR do?

This PR extracts booking preparation logic into a dedicated BookingDataPreparationService as part 4 of the booking flow refactor series. The main changes include:

• New BookingDataPreparationService: Centralizes all booking data preparation, validation, transformation, and enrichment logic into a single testable service class
• Repository pattern adoption: Adds methods to BookingRepository and UserRepository to abstract Prisma queries used during preparation
• Helper function refactoring: Updates checkIfBookerEmailIsBlocked and checkActiveBookingsLimitForBooker to use repository pattern instead of direct Prisma calls
• DI integration: Full dependency injection setup with module, tokens, and container wiring
• API v2 support: Wrapper service for API v2 with proper NestJS integration
• Comprehensive test coverage: Adds 1000+ lines of unit tests for the preparation service

The service handles:

• Enrichment: Fetches and enriches event type data
• Validation: Time validation, email blocking, booking limits, email verification
• Transformation: Converts raw booking data into structured format
• Preparation: Organizes data into categories (booker, routing, meta, config, etc.)

This is a pure refactoring - no functional behavior changes, just improved code organization and testability.

• Fixes PRI-305

Updates Since Last Revision

Latest changes (DI module + API v2 integration):

• Created BookingDataPreparationService.module.ts with proper DI wiring using bindModuleToClassOnToken
• Added DI tokens (BOOKING_DATA_PREPARATION_SERVICE, BOOKING_DATA_PREPARATION_SERVICE_MODULE) to tokens.ts
• Updated RegularBookingService.module.ts to include bookingDataPreparationService dependency
• Created API v2 wrapper service (apps/api/v2/src/lib/services/booking-data-preparation.service.ts)
• Updated API v2 regular-booking.service.ts to inject and pass BookingDataPreparationService
• Updated API v2 regular-booking.module.ts to include the new service provider
• Exported BookingDataPreparationService from @calcom/platform-libraries/bookings
• Updated BookingDataPreparationService to use Logger<unknown> type from tslog for API v2 compatibility

Previous changes (merge conflict resolution + interface update):

• Resolved merge conflicts with main branch
• Added bookingDataPreparationService: BookingDataPreparationService to IBookingServiceDependencies interface
• Updated findActiveBookingsForEventType repository method to include bookingSeat selection for seated events

Repository Methods

BookingRepository:

• countActiveBookingsForEventType: Counts active bookings for a booker by email
• findActiveBookingsForEventType: Finds active bookings with ordering and includes bookingSeat for seated events

UserRepository:

• findVerifiedUserByEmail: Finds verified users checking both primary and secondary emails

Visual Demo

N/A - This is a pure refactoring PR with no UI changes.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• N/A - No documentation changes required (internal refactoring only)
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Unit Tests

cd ~/repos/cal.com
TZ=UTC yarn test packages/features/bookings/lib/utils/BookingDataPreparationService.test.ts

Integration Testing

Run the full booking flow to ensure preparation still works:

1. Create a booking on an event type
2. Try booking with a blocked email (if configured)
3. Try exceeding booking limits (if configured on event type)
4. Try booking outside allowed time bounds
5. Verify email verification flow (if enabled on event type)

Human Review Checklist

Critical areas to review:

1. API v2 Logger type cast (HIGH PRIORITY):

   • apps/api/v2/src/lib/services/booking-data-preparation.service.ts uses bridgeLogger as unknown as TsLogger<unknown>
   • Verify the Logger bridge implements all methods used by BookingDataPreparationService (currently warn, info)

2. Repository pattern migration (HIGH PRIORITY):

   • checkIfBookerEmailIsBlocked now requires userRepository parameter - verify all callers are updated
   • checkActiveBookingsLimitForBooker now requires bookingRepository parameter - verify all callers are updated
   • These are breaking changes to the function signatures

3. Repository query equivalence (HIGH PRIORITY):

   • BookingRepository.countActiveBookingsForEventType - Does it correctly count active bookings?
   • BookingRepository.findActiveBookingsForEventType - Does ordering, limit, and bookingSeat selection work correctly?
   • UserRepository.findVerifiedUserByEmail - Does it check both primary and secondary emails correctly?

4. DI wiring completeness:

   • Verify BookingDataPreparationService.module.ts correctly wires all dependencies (log, bookingRepository, userRepository)
   • Verify RegularBookingService.module.ts includes the new bookingDataPreparationService dependency

Notes

• This is PR Unable to login if running on custom port #4 in a stacked series (depends on other booking flow refactor PRs)
• Part of broader effort to improve booking flow architecture
• No functional changes expected - pure refactoring for better code organization
• Full integration with RegularBookingService.handler() will come in a follow-up PR

Link to Devin run: https://app.devin.ai/sessions/1f56530a5ce1411894caca3c387d5e64
Requested by: hariom@cal.com (@hariombalhara)