fix: expose participantIdentity on RoomEvent.DataReceived - #2092
fix: expose participantIdentity on RoomEvent.DataReceived#2092mariusgassen wants to merge 1 commit into
Conversation
- `handleDataPacket` had `packet.participantIdentity` but dropped it before passing to `handleUserPacket` - added as required param internally, optional trailing arg on `RoomEventCallbacks.dataReceived` - allows callers to buffer and replay messages when the sender hasn't joined yet (data channel / participant join race)
|
|
thanks for the PR. This race shouldn't occur anymore in practice as the server is buffering messages for some time until a participant becomes active. |
Are you refering to this commit? I was running livekit-server 1.13.2 when implementing a client side buffering of messages with unknown remote participant senders. The original scenario was caused by our application's internal protocol. Participants would only accept messages from certain other participants. Without being able to check the sender (message sent directly after join, received before the sender was known as a remote participant), the messages were just discarded. Edit: The race we hit is purely on the client side: the data channel message (WebRTC) arrives before the participant update (join) signal (WebSocket) and the We can reproduce it by having a participant send a data message immediately on connected, before the receiving participant has had a chance to process the join signal. Our solution is a client side buffering of messages with no known remote participant - requiring this PRs change. We already observed and implemented something similar on the server component side: |

handleDataPackethadpacket.participantIdentitybut dropped it before passing tohandleUserPacketRoomEventCallbacks.dataReceived