Saving booking request takes forever

[buzzard10]

Found a bug? Please fill out the sections below. 👍

Issue Summary

I don't know why, but scheduling meeting takes forever, below you have a video - same with approving meeting from user panel. Because of that clients don't know whether they successfully scheduled a meeting. It takes over a minute for sure!

20260116-0803-15.7131269.mp4

Steps to Reproduce

Schedule a new meeting

Actual Results

• It takes longer than it should

Expected Results

• It should work in few seconds

[linear]

CAL-7078

[Bunny099]

I like to work on this issue.

[buzzard10]

I can deliver any logs you want :)

[Ayuussshhh]

@buzzard10 to investigate this properly, could you please provide the logs from the time when the meeting is scheduled and approved?
Once I have those, I can dig into what’s causing the delay.

[leafmintaiAR]

structurally this looks like a synchronous processing issue rather than a core booking bug

The booking creation path persists correctly, but post-booking notifications (emails, SMS, webhooks) are processed synchronously inside BookingEmailAndSmsTasker

Because the notifications arent queued asynchronously the API response waits for all tasks to complete before returning

There are also multiple layers of handling (createBooking, bookings.service.ts, booking-event-handler.service.ts) which suggests tight coupling between booking creation and notification processing

Structurally this points to:

booking creation completing correctly

but notification processing blocking the main thread

That would explain why bookings succeed but users experience multisecond delays

[buzzard10]

@Ayuussshhh can you look at my comment here? It was related to accepting schedule meeting only, but now i see that clients are also have this problem..
#25009 (comment)

[buzzard10]

@leafmintaiAR i have also issue with notifications that they're not going out..

[Ayuussshhh]

@buzzard10 I can see the issue, would it be alright for you to go in the network section and see which page is getting the error, send me the payload for that.
So that I can focus on that as in the screenshot, we are also getting the server response 401.
Please look into that and if possible, share the screenshot of that too.

[buzzard10]

Sure! It’ll be ready in 20 minutes :) Thanks for your interest in this matter.

[leafmintaiAR]

@buzzard10 That actually reinforces the same structural problem

When notification dispatch lives on the booking execution path you get both failure modes:

blocking when everything runs synchronously

silent drops when partial failures arent retried or isolated

If notifications were fully decoupled (queued + retried independently), booking latency and delivery reliability wouldnt be coupled.

Thats why it shows up both as slow bookings and missing notifications same structural boundary issue two symptoms

[buzzard10]

@leafmintaiAR so do i have to provide any additional information? Or the problem is already known?

[leafmintaiAR]

@buzzard10 The logs you shared are mostly frontend render errors and wont affect booking creation time directly

To isolate the delay we need to confirm whether the booking API response itself is slow or the UI is blocked by follow-up calls.

Could you open DevTools → Network, filter by createBooking (or the booking POST endpoint), and share:

response time

status code

whether the delay is before or after the response is returned