chore: Integrate confirmation booking audit

[hariombalhara]

What does this PR do?

Integrates booking audit logging for booking confirmation (acceptance) and rejection events. This is part of the booking audit integration plan (PR-2).

Note: This PR is stacked on #26567 which refactors the link and verify-booking-token routes to use confirmHandler directly instead of the tRPC caller pattern.

Core Changes:

• handleConfirmation.ts: Added audit logging for single booking acceptance (onBookingAccepted) and bulk/recurring booking acceptance (onBulkBookingsAccepted). Refactored to use SimplifiedActorIdentifier union type for flexible actor specification.
• confirm.handler.ts: Added audit logging for booking rejection (onBookingRejected) via fireRejectionEvent helper. Passes actionSource/userUuid to handleConfirmation. Input type now requires actionSource and actor.
• zod-utils.ts: Added required actionSource field to the booking confirm input schema (values: WEBAPP, API_V1, API_V2, WEBHOOK, MAGIC_LINK)
• _router.tsx: Explicitly adds actionSource: "WEBAPP" and actor when calling confirmHandler from tRPC
• API v2 bookings.service.ts: Passes actionSource: "API_V2" and actor for confirm and decline operations
• link/route.ts & verify-booking-token/route.ts: Pass actionSource: "MAGIC_LINK" and actor for magic link confirmations

Payment Webhook Integration:

• handlePaymentSuccess.ts: Refactored to accept object params including appSlug for actor identification. Creates app actor from credentialId or falls back to appSlug.
• Payment webhooks (alby, btcpayserver, hitpay, paypal, stripe): Updated to pass their respective appSlug for audit actor identification
• Stripe webhook.ts: Added actor creation for payment setup success flow

Schema Changes:

• schema.prisma: Added MAGIC_LINK to BookingAuditSource enum
• Migration: Added 20260107093019_add_magic_link_source migration
• RejectedAuditActionService.ts: Changed rejectionReason from StringChangeSchema (old/new) to z.string().nullable() (single value). Changed status to use BookingStatusChangeSchema.
• dto/types.ts: Added ActorIdentification type export

Test Infrastructure:

• Refactored integration test utilities into reusable integration-utils.ts
• Updated route tests to mock confirmHandler directly and include makeUserActor mock

Updates since last revision

• PR is now stacked on refactor: Use confirmHandler directly in link and verify-booking-token routes[booking-audit-prerequisite] #26567 (refactor: Use confirmHandler directly in link and verify-booking-token routes)
• Added MAGIC_LINK as a new BookingAuditSource enum value with corresponding migration
• Magic link routes (/api/link and /api/verify-booking-token) now pass actionSource: "MAGIC_LINK" and actor to confirmHandler
• Updated tests to verify actor is passed correctly from makeUserActor

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A - internal audit logging only.
• I confirm automated tests are in place that prove my fix is effective or that my feature works. N/A - audit logging is non-blocking and wrapped in try-catch.

How should this be tested?

1. Accept a single booking → verify audit log is created with onBookingAccepted
2. Accept recurring bookings → verify audit logs are created with onBulkBookingsAccepted and share the same operationId
3. Reject a booking → verify audit log is created with onBookingRejected
4. Confirm/decline via API v2 → verify actionSource is "API_V2"
5. Complete a payment via Stripe/PayPal/etc → verify audit log has correct app actor
6. New: Confirm via magic link → verify actionSource is "MAGIC_LINK"

Human Review Checklist

• Verify PR refactor: Use confirmHandler directly in link and verify-booking-token routes[booking-audit-prerequisite] #26567 is merged before this PR (stacked dependency)
• Verify the MAGIC_LINK migration runs correctly
• Verify all callers of handleConfirmation pass required actionSource and either userUuid or actor
• Verify the SimplifiedActorIdentifier union type correctly enforces mutual exclusivity of userUuid and actor
• Verify payment webhook handlers correctly identify their app via appSlug
• Verify the RejectedAuditData schema change (rejectionReason no longer has old/new) is acceptable
• Verify the guard clause behavior (skipping audit when actor is undefined) is acceptable
• Note: Bulk rejection (recurring events) currently only logs the primary booking, not all related bookings - confirm if this is acceptable

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have checked if my changes generate no new warnings

---

Link to Devin run: https://app.devin.ai/sessions/5914b63665314f9480f0cf5fd2d6fd13
Requested by: @hariombalhara

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
cal-com-v2	Building	Preview, Comment	Jan 8, 2026 9:31am
cal-com-v2-1767797589266-uOAD	Canceled		Jan 8, 2026 9:31am
cal-com-v2-5dan	Canceled		Jan 8, 2026 9:31am

4 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
api-v2	Ignored	Preview	Jan 8, 2026 9:31am
cal	Ignored		Jan 8, 2026 9:31am
cal-companion	Ignored	Preview	Jan 8, 2026 9:31am
cal-eu	Ignored		Jan 8, 2026 9:31am

[cubic-dev-ai]

7 issues found across 26 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="apps/web/app/api/verify-booking-token/__tests__/route.test.ts">

<violation number="1" location="apps/web/app/api/verify-booking-token/__tests__/route.test.ts:349">
P2: Test does not verify that `actor` is passed to `confirmHandler` for the reject action. Add `actor: { type: "user", id: "test-uuid" }` to the assertion to verify audit actor is passed correctly.</violation>

<violation number="2" location="apps/web/app/api/verify-booking-token/__tests__/route.test.ts:371">
P2: Test 'should redirect with error when user not found' is missing the assertion `expect(mockConfirmHandler).not.toHaveBeenCalled()`. The parallel test for 'booking not found' includes this check - add it here for consistency and to verify the handler isn't called when user lookup fails.</violation>
</file>

<file name="packages/features/booking-audit/lib/service/__tests__/accepted-action.integration-test.ts">

<violation number="1" location="packages/features/booking-audit/lib/service/__tests__/accepted-action.integration-test.ts:69">
P2: Test cleanup for `booking2` and `booking3` is unreliable. If any assertion fails before reaching the cleanup code, these bookings won't be deleted, causing test pollution. Consider tracking dynamically created bookings in an array and cleaning them up in `afterEach`, or wrap the test body in a try/finally block to ensure cleanup runs regardless of test outcome.</violation>
</file>

<file name="packages/features/booking-audit/lib/types/actionSource.ts">

<violation number="1" location="packages/features/booking-audit/lib/types/actionSource.ts:3">
P3: Typo in comment: "explcit" should be "explicit".</violation>
</file>

<file name="packages/features/bookings/lib/handleConfirmation.ts">

<violation number="1" location="packages/features/bookings/lib/handleConfirmation.ts:409">
P2: Missing error handling: `fireBookingAcceptedEvent` should be wrapped in try-catch to prevent audit failures from breaking booking confirmation. The PR description states audit logging should be non-blocking, and other similar operations in this file (workflow scheduling) follow this pattern.</violation>
</file>

<file name="packages/trpc/server/routers/viewer/bookings/confirm.handler.ts">

<violation number="1" location="packages/trpc/server/routers/viewer/bookings/confirm.handler.ts:468">
P2: Missing try-catch around `fireRejectionEvent` call. The PR description states audit logging should be non-blocking and wrapped in try-catch, but this await has no error handling. If the audit service fails, it will cause the booking rejection handler to fail even though the database updates have already been committed, leading to inconsistent state and missed webhooks.</violation>
</file>

<file name="packages/features/booking-audit/lib/actions/RejectedAuditActionService.ts">

<violation number="1" location="packages/features/booking-audit/lib/actions/RejectedAuditActionService.ts:20">
P2: Schema shape change for `rejectionReason` (from `{ old, new }` object to simple string) without incrementing VERSION or adding migration logic. If any existing data exists with the old format, `parseStored` and `migrateToLatest` will fail. Consider either:
1. Incrementing VERSION to 2 and adding migration logic in `migrateToLatest` to transform `{ old, new }` → `new`
2. Adding a comment confirming no production data exists yet with this schema</violation>
</file>

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

[Udit-takkar]

We have too many functions like makeUserActor, makeGuestActor. We should just create a single factory class that would handle all the different types

[hariombalhara]

I would have to think about it, though I will implement in a followup.

Do you have something specific in mind?

The way I see it a route/Service would have to specifically identify what kind of actor took the action. That decision is pretty specific to the route depdning on what data is passed to it.

Once it knows what actor it needs to use, it just needs to call appropriate fn. But I totally feel it can be improved, in some way,

[Udit-takkar]

LGTM. just few small followups

[alishaz-polymath]

Let's go 🚀 🚀 🚀