bug: Potential main-thread deadlock in EmbeddedChatApi.ts when typingHandlerLock remains set

[jhalak101205-cpu]

Bug Description

When running EmbeddedChat and receiving typing status notifications over the DDP WebSocket connection, the browser tab completely freezes and becomes unresponsive (causing a white screen or canvas freeze in Storybook / React applications).

---

Root Cause Analysis

Inside packages/api/src/EmbeddedChatApi.ts, the function handleTypingEvent contains a synchronous busy-wait loop:

// packages/api/src/EmbeddedChatApi.ts (Line 456)
setTimeout(() => {
  typingHandlerLock = 0;
}, 2000);

while (typingHandlerLock) {} // <--- Critical Bug
typingHandlerLock = 1;

[jhalak101205-cpu]

@Spiral-Memory plz do see it once you are free and give a review so that I can proceed with the PR.

[Spiral-Memory]

@Aryan-Verma-999 Pls look into this and guide him / fix it accordingly

[jhalak101205-cpu]

@Aryan-Verma-999 looking forward to your guidance and learning that I'll get from you .

[Aryan-Verma-999]

Thanks @jhalak101205-cpu for reporting this. I tested typing in Storybook but couldn’t reproduce the freeze through normal usage. Could you please share a short recording showing the issue, along with the browser, and reproduction steps?

However, the synchronous busy-wait is still invalid and can deadlock the main thread whenever the lock is left set.
once the reproduction details are confirmed, you can proceed with a PR removing the lock :)

[jhalak101205-cpu]

Hi @Aryan-Verma-999, You are correct . Under single-user typing, typingHandlerLock starts at 0, so while (typingHandlerLock) evaluates to false and doesn't trigger a freeze during basic manual testing. But I think it will hit the deadlock condition if there are Concurrent Typing Events . If a second user types at the same time the typingHandlerLock === 1, while (typingHandlerLock) becomes while (1) {}. But since JS uses one command at once or single thread language the while loop starves the main thread, preventing the setTimeout callback on line 452 from ever firing to set typingHandlerLock = 0.

I think there can be also an exceptional case if typingHandlerLock remains stuck at 1 which will create a permanent deadlock.

Environment

• Browser: Google Chrome v126+ (macOS)
• Component: packages/api/src/EmbeddedChatApi.ts (handleTypingEvent)

Reproduction Steps

1. Open EmbeddedChat on localhost (http://localhost:5173/ or Storybook).
2. Open Chrome Developer Console (Cmd + Option + I).
3. Trigger concurrent handleTypingEvent calls or simulate typingHandlerLock === 1.
4. Observe that while (typingHandlerLock) {} (Line 456) enters a synchronous infinite loop on the main browser thread.

Here given below is the recording :

screen_recording.mp4

[Aryan-Verma-999]

Thanks for the recording and detailed explanation @jhalak101205-cpu :)

I also simulated multiple typing events from more than two users arriving in the same event-loop turn. They were processed sequentially and the browser remained responsive. This is expected because JavaScript does not execute these callbacks concurrently. Each handler completes and resets typingHandlerLock before the next queued event runs. Therefore, multiple users typing alone does not directly set the lock to 1 for the next handler.

The actual deadlock occurs if typingHandlerLock is already stuck at 1. In that case, the while loop blocks the main thread, so the setTimeout callback can never run to reset the lock.

The implementation is still unsafe and the busy-wait is unnecessary. Please proceed with a PR removing the global lock, timeout, and while loop, while preserving the typing-user update logic. Update the issue wording to describe this as a potential deadlock when the lock remains set, rather than as direct concurrency between users.

[jhalak101205-cpu]

Thanks @Aryan-Verma-999 for the detailed explanation! That really helped clarify how the Event Loop handles sequential task execution and why the lock mechanism is unnecessary here.

As requested, I have updated the issue title and description. I am preparing the PR to remove the global lock, timeout, and while-loop while keeping the typing user update logic intact. If I run into any questions or doubts while finalizing it, I’ll be sure to reach out to you!

Thanks again for your guidance and review.

[jhalak101205-cpu]

Hey , @Spiral-Memory I have raised a PR . Plz review it and tell me if it's working or any test its failing from your end. I have basically performed 4 test on this.

1. Rapid Burst Test (100 Events): I ran a loop firing 100 typing events back-to-back in under 1ms. I wanted to see how it handles microsecond network bursts when multiple users are typing in a busy room. It processed all 100 events in < 1ms with zero tab lag or CPU freeze.
2. Start / Stop Toggle Test: Tested rapid typing and stopping (triggering typing true then false 50 times fast for the same user). This was to check if splice and unshift clean up the array properly without leaving duplicate user entries when someone types and backspaces quickly.
3. Multi-User Ordering Test: Simulated 5 different users typing at the same time and then 2 stopping. Verified that this.typingUsers keeps the latest typing user right at the top (index 0) and removes users cleanly when they stop.
4. Monorepo Build Test: Ran yarn build across all workspace packages (@embeddedchat/api, @embeddedchat/react, etc.) to be sure removing typingHandlerLock compiles cleanly without breaking any dependent packages.

Do tell me if there's any other possibility of hit case if I have missed any . I will work on it accordingly ^-^

[jhalak101205-cpu]

@Spiral-Memory and @Aryan-Verma-999 please review the PR and let me know the changes I have to do?? If any.