RocketChat / RocketChat/EmbeddedChat
bug: Potential main-thread deadlock in EmbeddedChatApi.ts when typingHandlerLock remains set
Nobody has claimed this yet.
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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