RocketChat / RocketChat/EmbeddedChat

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

Open
#1,354 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
JavaScript
Stars
165
Forks
381
Avg merge
1d 2h
Merged PRs (30d)
1

Description

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;

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in packages/api/src/EmbeddedChatApi.ts at handleTypingEvent and inspect how typing notifications arrive over the DDP WebSocket connection. Reproduce the freeze while receiving typing status updates, then verify that the browser remains responsive and typing events continue to be handled without the lock blocking the main thread.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
api, frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.