fix: dispose track publication handles on participant disconnect#634
fix: dispose track publication handles on participant disconnect#634LautaroPetaccio wants to merge 8 commits intolivekit:mainfrom
Conversation
🦋 Changeset detectedLatest commit: 7605e1c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
packages/livekit-rtc/src/room.ts
Outdated
| participant.info.disconnectReason = ev.value.disconnectReason; | ||
| // Emit before disposing so listeners can still access trackPublications. | ||
| this.emit(RoomEvent.ParticipantDisconnected, participant); | ||
| // Dispose each track publication's FfiHandle to prevent FD leaks. |
There was a problem hiding this comment.
for disconnecting participants we first receive a trackUnpublished event, which would arguably be the more obvious place to perform this cleanup.
Agree though, that the cleanup needs to happen at some point.
We could wrap it in queueMicrotask in the trackUnpublished handler.
There was a problem hiding this comment.
The trackUnpublished handler currently doesn't dispose the FfiHandles either, it only removes the publication from the Map. So this would mean adding new disposal logic there, not moving it. I went with participantDisconnected as a single cleanup sweep that catches everything regardless of whether trackUnpublished fired for each track. Happy to move it if you feel strongly though.
There was a problem hiding this comment.
Yeah, sorry for the confusion. I meant adding your new disposal logic to the trackUnpublished handler instead. The main reason I would prefer it there is that a participant could, in theory, publish and subsequently unpublish hundreds of tracks before ever disconnecting.
Move the primary disposal to the trackUnpublished handler so handles are freed as soon as tracks are unpublished, preventing accumulation during long-lived sessions with track churn. Keep the sweep in participantDisconnected as a safety net for abrupt disconnects where individual trackUnpublished events may not fire.
trackUnpublished events always fire before participantDisconnected (the SDK already depends on this ordering via requireRemoteParticipant), so the safety-net loop was dead code. The eager disposal in the trackUnpublished handler is sufficient.
LautaroPetaccio
force-pushed
the
fix/dispose-track-publications-on-disconnect
branch
from
b1cd48c to
251b6d5
Compare
There was a problem hiding this comment.
🟡 participantDisconnected handler does not dispose remaining publication FfiHandles, causing FD leaks if trackUnpublished events are skipped
The PR's stated intent is to prevent FD leaks from track publication handles on participant disconnect, but the disposal is only added in the trackUnpublished handler (room.ts:451). The participantDisconnected handler (room.ts:408-416) removes the participant from remoteParticipants without disposing any remaining publication ffiHandles. If trackUnpublished events don't fire for every track before participantDisconnected (e.g., during abrupt disconnects or server-side removals), those handles will leak — the exact scenario the PR aims to fix. The test at line 562 asserts trackPublications.size === 0, validating only the happy path where trackUnpublished precedes participantDisconnected. A defensive cleanup loop in the participantDisconnected handler would close this gap.
(Refers to lines 410-413)
Was this helpful? React with 👍 or 👎 to provide feedback.
2 participants
Why
When the room processes a
participantDisconnectedevent, it deletes the participant from theremoteParticipantsmap and emits an event — but never touches the participant'strackPublications. EachTrackPublicationwraps anFfiHandlethat maps to a native resource. Dropping the JS reference without callingdispose()means the native side never frees the handle. With N participants each publishing M tracks, every disconnect leaks N×M handles.How
In the
participantDisconnectedevent handler, before emitting the event, loop throughparticipant.trackPublications, callffiHandle.dispose()on each publication, and clear the map.Test coverage
cleans up track publications when a remote participant disconnects— publishes a track, disconnects the publisher, assertstrackPublicationsis empty on the observer sidecleans up resources when multiple participants disconnect simultaneously— 4 participants each with a track, all disconnect at once