Problem
The workspace broadcast listener carries state and a handler that do nothing.
The typing map has no reader. useBroadcastListener writes every typing event into workspaceSettings.typingIndicators through setTypingIndicator and removeTypingIndicator (apps/webapp/src/hooks/useBroadcastListener.ts:46-55, apps/webapp/src/stores/chat/workspaceSettingsStore.ts:8, :19-20, :30, :60-80). Nothing reads that map. The visible typing state comes from the same handler's updateUserStatus(..., 'TYPING') call, which feeds the avatar stacks.
An unused field sits next to it. workspaceSettings.activeChannelId (workspaceSettingsStore.ts:7) is never written or read. Its comment points at the typing map.
The pin handler has no sender. Nothing sends a pinnedMessage broadcast. The only send is commented out (apps/webapp/src/components/chatroom/components/MessageCard/hooks/usePinMessageHandler.ts:30-34). The pinner updates its own store directly. So the pin handler (useBroadcastListener.ts:36-45) never runs.
Acceptance criteria
Agent Brief
Category: enhancement
Summary: Remove the unused typing map and the unused activeChannelId field, and remove the pin listener that has no sender.
Current behavior:
Typing events fill a map that nothing reads. A store field has no writer and no reader. A pinnedMessage listener waits for a broadcast that nothing sends.
Desired behavior:
Typing events only update user status. The dead field is gone. The pin listener and the commented-out send are gone.
Key interfaces:
useBroadcastListener(enabled) — mounted once in AppProviders.
setTypingIndicator and removeTypingIndicator — write the typing map.
updateUserStatus(userId, status) — writes the TYPING status that the avatar stacks read.
- The commented-out
pinnedMessage send in the pin handler hook.
Out of scope
Notes
The listener's cleanup does not detach its handlers. A code trace and a harness on 14ab7f9c1 show that this adds no second handler set today. At mount the channel does not exist yet, and a route change builds a new channel. Only a Fast Refresh edit in development can run the effect again on the same channel.
Problem
The workspace broadcast listener carries state and a handler that do nothing.
The typing map has no reader.
useBroadcastListenerwrites every typing event intoworkspaceSettings.typingIndicatorsthroughsetTypingIndicatorandremoveTypingIndicator(apps/webapp/src/hooks/useBroadcastListener.ts:46-55,apps/webapp/src/stores/chat/workspaceSettingsStore.ts:8,:19-20,:30,:60-80). Nothing reads that map. The visible typing state comes from the same handler'supdateUserStatus(..., 'TYPING')call, which feeds the avatar stacks.An unused field sits next to it.
workspaceSettings.activeChannelId(workspaceSettingsStore.ts:7) is never written or read. Its comment points at the typing map.The pin handler has no sender. Nothing sends a
pinnedMessagebroadcast. The only send is commented out (apps/webapp/src/components/chatroom/components/MessageCard/hooks/usePinMessageHandler.ts:30-34). The pinner updates its own store directly. So the pin handler (useBroadcastListener.ts:36-45) never runs.Acceptance criteria
activeChannelIdstore field are removed.pinnedMessagelistener and the commented-out send are removed.bun run typecheckpasses.Agent Brief
Category: enhancement
Summary: Remove the unused typing map and the unused
activeChannelIdfield, and remove the pin listener that has no sender.Current behavior:
Typing events fill a map that nothing reads. A store field has no writer and no reader. A
pinnedMessagelistener waits for a broadcast that nothing sends.Desired behavior:
Typing events only update user status. The dead field is gone. The pin listener and the commented-out send are gone.
Key interfaces:
useBroadcastListener(enabled)— mounted once inAppProviders.setTypingIndicatorandremoveTypingIndicator— write the typing map.updateUserStatus(userId, status)— writes theTYPINGstatus that the avatar stacks read.pinnedMessagesend in the pin handler hook.Out of scope
handleTypingIndicator.Notes
The listener's cleanup does not detach its handlers. A code trace and a harness on
14ab7f9c1show that this adds no second handler set today. At mount the channel does not exist yet, and a route change builds a new channel. Only a Fast Refresh edit in development can run the effect again on the same channel.