Skip to content

Conversation

lukasIO
Copy link
Contributor

@lukasIO lukasIO commented Oct 8, 2025

For some actions (i.e. publishing + unpublishing a track) the local participant needs to acquire the processing lock to ensure any state updates are done before emitting other events on the room level.

Copy link

changeset-bot bot commented Oct 8, 2025

🦋 Changeset detected

Latest commit: 15a2fbc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages
Name Type
@livekit/rtc-node Patch
@livekit/rtc-node-darwin-arm64 Patch
@livekit/rtc-node-darwin-x64 Patch
@livekit/rtc-node-linux-arm64-gnu Patch
@livekit/rtc-node-linux-x64-gnu Patch
@livekit/rtc-node-win32-x64-msvc Patch

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

Copy link
Contributor

@Shubhrakanti Shubhrakanti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty much the same as pythons implementation looks good to me

Copy link

@xianshijing-lk xianshijing-lk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, two thoughts. Thanks for fixing the problems.

return ev.message.case == 'publishTrack' && ev.message.value.asyncId == res.asyncId;
});
try {
const cb = await FfiClient.instance.waitFor<PublishTrackCallback>((ev) => {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought(non-blocking)
curiously, does FfiClient.instance.request guarantee that it will trigger a PublishTrackCallback later ?

There is no need to change it now, but just an idea, I wonder if it makes sense to do things like

  1. prepare a waiter
  2. roomEventLock.lock()
  3. FfiClient.instance.request
  4. waiter.setAsyncId(res.asyncId)
  5. waiter will wait with some timeout, like await waiter.wait({ timeoutMs: 50 }); // not sure if that will bring more flakiness or less here.

if (ev.case == 'participantConnected') {
const participant = this.createRemoteParticipant(ev.value.info!);
this.remoteParticipants.set(participant.identity!, participant);
this.emit(RoomEvent.ParticipantConnected, participant);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion(non-blocking)
I have some concerns on this emit event since it is fired under the lock, and I wonder if it is a better pattern if we do things like

const unlock = await this.roomEventLock.lock();
const toEmit: Array<() => void> = [];

try {
// Push all the emit events in sequence to the array
toEmit.push(...);
} finally {
unlock();
}

// Fire the emit events
for (const fire of toEmit) {
try {
fire(); // consider await fire() ? if we need them to be synchronous
} catch ...
}

it is a suggestion, no need to work on it if you think the emit events are safe anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants