fix: generate unique videoCallUrl per recurring booking occurrence

[ajayjha1]

Fixes the bug where all recurring booking occurrences shared the same videoCallUrl.

Issue
When creating a recurring booking with Cal Video enabled:

All occurrences were assigned the same videoCallUrl (from the first booking's uid)
Future meetings pointed to the first occurrence's video room link
If the first link expired, all later meetings would break
Fix
For Cal Video (daily_video), each recurring booking occurrence now gets its own unique video room URL derived from its own uid:

occurrence 1 → .../video/uid-1
occurrence 2 → .../video/uid-2
occurrence 3 → .../video/uid-3
For other providers (Zoom, Google Meet, Teams), the shared meeting URL behavior is preserved since those integrations create one meeting per series by design.

Evidence
Existing FIXME comments in recurring-event.test.ts acknowledged this bug
Code inspection confirmed handleConfirmation.ts computed a single meetingUrl and applied it to all recurring bookings in the loop
Fixes #28871

[github-actions]

Welcome to Cal.diy, @ajayjha1! Thanks for opening this pull request.

A few things to keep in mind:

• This is Cal.diy, not Cal.com. Cal.diy is a community-driven, fully open-source fork of Cal.com licensed under MIT. Your changes here will be part of Cal.diy — they will not be deployed to the Cal.com production app.
• Please review our Contributing Guidelines if you haven't already.
• Make sure your PR title follows the Conventional Commits format.

A maintainer will review your PR soon. Thanks for contributing!

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ce509abd-0f60-4909-9c09-0d8def3faf32

📥 Commits

Reviewing files that changed from the base of the PR and between 8de7b2d and 4e4796b.

📒 Files selected for processing (1)

• packages/features/bookings/lib/handleConfirmation.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• packages/features/bookings/lib/handleConfirmation.ts

---

📝 Walkthrough

Walkthrough

Removed FIXME comment lines from three test assertions that referenced recurring bookings sharing the same video URL. In confirmation handling, recurring-booking updates now compute a per-occurrence metadata.videoCallUrl when the event’s videoCallData indicates a daily Cal Video (isDailyVideoCall), deriving each URL from the occurrence uid via getPublicVideoCallUrl. For non-daily video types the code continues to use the series-level meetingUrl. The series-level webhook payload still includes meetingUrl (first occurrence), while per-occurrence URLs are stored on each booking.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: generating unique videoCallUrl for each recurring booking occurrence, which directly addresses the core bug fix.
Description check	✅ Passed	The description clearly explains the bug, the fix, and why it matters, with evidence from comments and code inspection, all directly related to the changeset.
Linked Issues check	✅ Passed	The changeset directly addresses #28871 by implementing per-occurrence videoCallUrl generation for Cal Video in handleConfirmation.ts and removing FIXME comments from recurring-event.test.ts.
Out of Scope Changes check	✅ Passed	All changes are scoped to the linked issue: modifications to handleConfirmation.ts for per-occurrence URL logic and test cleanup in recurring-event.test.ts with no unrelated alterations.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/features/bookings/lib/handleConfirmation.ts (1)

408-417: ⚠️ Potential issue | 🟡 Minor

Webhook BOOKING_CREATED payload diverges from per-occurrence DB storage for recurring Cal Video.

The webhook payload at line 415 emits a shared videoCallUrl (derived from evt.videoCallData?.url, the primary/first occurrence's room), while the DB stores unique metadata.videoCallUrl per occurrence for Cal Video (lines 180-184). For recurring Cal Video events, subscribers receive only the first occurrence's URL via the single series-level webhook and cannot reconstruct per-occurrence URLs without re-querying the DB.

Consider clarifying whether the single webhook per series is intentional or whether per-occurrence webhook payloads are expected. If the current design is intentional, document this constraint for webhook consumers.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/features/bookings/lib/handleConfirmation.ts` around lines 408 - 417,
The webhook payload currently uses meetingUrl (evt.videoCallData?.url /
meetingUrl) when building payload in the payload object, which emits the
series-level room while the DB stores per-occurrence metadata.videoCallUrl;
change payload construction in the block that builds payload (the payload
constant in handleConfirmation.ts) to prefer the occurrence-specific URL from
booking.metadata.videoCallUrl (or booking.metadata?.videoCallUrl) when present
and fall back to meetingUrl, e.g. set metadata: meetingUrl ? { videoCallUrl:
booking.metadata?.videoCallUrl || meetingUrl } : (booking.metadata || {});
additionally, if this behavior is intentional (single series webhook only), add
a short comment and update webhook docs to state consumers must re-query
per-occurrence URLs from the DB.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@packages/features/bookings/lib/handleConfirmation.ts`:
- Around line 408-417: The webhook payload currently uses meetingUrl
(evt.videoCallData?.url / meetingUrl) when building payload in the payload
object, which emits the series-level room while the DB stores per-occurrence
metadata.videoCallUrl; change payload construction in the block that builds
payload (the payload constant in handleConfirmation.ts) to prefer the
occurrence-specific URL from booking.metadata.videoCallUrl (or
booking.metadata?.videoCallUrl) when present and fall back to meetingUrl, e.g.
set metadata: meetingUrl ? { videoCallUrl: booking.metadata?.videoCallUrl ||
meetingUrl } : (booking.metadata || {}); additionally, if this behavior is
intentional (single series webhook only), add a short comment and update webhook
docs to state consumers must re-query per-occurrence URLs from the DB.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d12a6279-7acd-4f0f-8763-902a5b6a6273

📥 Commits

Reviewing files that changed from the base of the PR and between 9efd0e6 and 8de7b2d.

📒 Files selected for processing (2)

• apps/web/pages/api/book/recurring-event.test.ts
• packages/features/bookings/lib/handleConfirmation.ts

💤 Files with no reviewable changes (1)

• apps/web/pages/api/book/recurring-event.test.ts