fix: cancellation reason is correctly recorded for seated bookings

[chaitanyya]

What does this PR do?

• Fixes https://github.com/calcom/cal.com/issues/21759
• Fixes CAL-XXXX

Mandatory Tasks (DO NOT REMOVE)

• [x] I have self-reviewed the code (A decent size PR without self-review might be rejected).
• [x] I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A
• [x] I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

1. Create an API key for your account
2. Create an event type with seats
3. Assign yourself as the host
4. Book a seat for that event type
5. Cancel the event using the API
6. The reason is correctly recorded

---

Summary by cubic

Fixed an issue where the cancellation reason was not saved when cancelling seated bookings via the API.

• Bug Fixes
  • Cancellation reason is now correctly recorded and returned for seated bookings.

[vercel[bot]]

@chaitanyya is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[graphite-app[bot]]

Graphite Automations

"Add consumer team as reviewer" took an action on this PR • (06/14/25)

1 reviewer was added to this PR based on Keith Williams's automation.

"Add community label" took an action on this PR • (06/14/25)

1 label was added to this PR based on Keith Williams's automation.

[chaitanyya]

@Devanshusharma2005 hey, do you mind taking a look at this? it's a quick one and I have added tests to make things easier :)

[ibex088]

LGTM, but will wait for @supalarry 's review

[supalarry]

Thanks for the contribution! We have updated docs https://cal.com/docs/api-reference/v2/bookings/cancel-a-booking to describe exactly how to cancel a seated booking from the perspective of an attendee and host, which is why I closed original issue and will close this PR too. Here is why:

It is not possible to pass cancellation reason while passing seatUid because of how cal com is currently structured in the backend - we have Booking table and even if one seat, two seat, three seats are booked there is only 1 existing Booking and 3 Attendee entries for each seat, but cancellation reason lives on the Booking model not on Attendee so if we would pass cancellation reason with seat uid, indeed like in the test, it ends up on the booking row, but what about providing cancellation reason for seat 2 and 3 - there is only 1 spot for cancellation reason, so for this to make sense we would have to restructure the backend.