Fix duplicate identity

[pblazej]

Resolves #958

After unpublishAll(), the sticky hasPublished flag kept the publisher transport marked as critical. When the idle publisher ICE timed out, this triggered an unnecessary reconnect cycle that escalated from quick to full, connecting without the reconnect flag and causing the server to remove the participant with DUPLICATE_IDENTITY.

Reset hasPublished to false when no track publications with non-nil tracks remain, preventing both the spurious reconnect trigger and unnecessary publisher ICE restarts during any server-initiated reconnect.

[Daltron]

@pblazej thank you for such a quick fix and solution! I can confirm that this does indeed fix the undesired reconnection issue from happening! However, it appears it introduced a new issue. If the LocalParticipant tries to republish their tracks after they unpublished them, the video and audio tracks are published (According to the delegates) but you can neither see them or hear them on either the local or remote sides.

However, on the RemoteParticipant side, only didPublishTrack is called for the audio track and the new video track never comes through. But like I mentioned, you are unable to hear them.

I can also confirm this was not an issue before this change because as soon as the undesired reconnection took place, we could successfully publish (and see and hear the tracks) again on all devices.

[pblazej]

@Daltron let me revisit it, will keep you posted.

[Daltron]

@pblazej really appreciate it, thank you!

[pblazej]

@Daltron I was unable to reproduce this particular regression in an isolated environment (killing ICE, blocking UDP, etc.).

However, I think there's another gap in the logic I tried to fix above ⬆️

It would be great to validate on your side (and provide full logs).

[Daltron]

@pblazej Unfortunately, the same issue persists to where local tracks can not be published a second time. I've attached logs which are broken down into sections which indicate what is triggered where:

livekit_logs.txt

[pblazej]

@Daltron I think I'd need full logs:

/* 10-15 seconds later */

on .debug level.

Preferably from main as well (with the original issue).

[Daltron]

@pblazej attached are the full logs from the blaze/duplicate-identity branch!
live_logs_full.txt

[pblazej]

@Daltron thanks for the full details, I think the root cause is in the transceiver cleanup (workaround)...

Added one more change - let's try to validate it ⬆️ 🤞

[pblazej]

@Daltron were you able to check it with the latest release (2.13.0)?

[Daltron]

@pblazej I have tested both the 2.13.0 release and this branch and nothing has changed unfortunately.

[pblazej]

@Daltron are you able to reproduce it locally in a reliable way? Any specific steps?

[Daltron]

@pblazej I am able to reproduce it 100% of the time locally:

1. On device A, create a room and start publishing local tracks (video and audio) to it
2. On device B, subscribe to that room (gives you tracks from Device A)
3. On device B, start publishing local tracks to that room
4. On device B, unpublish the local tracks but stay subscribed to device A's room

Two issues:

1. If you wait about 15 seconds, you will see that we lose device A's tracks on device B's for a split second but the reconnection successfully occurs and we get them back.
2. If you try to republish device B's local tracks before issue 1 finishes (before you wait 15 seconds and for the reconnect to occur), device A can not see device B's tracks. However if you wait for the reconnection to occur and then try to republish the local tracks, then it works perfectly.

[github-actions]

⚠️ This PR does not contain any files in the .changes directory.

[pblazej]

@boks1971 I tried to extract something from logs, do you think we can fix the regression server-side?

republish-server-timeline.md

[pblazej]

@Daltron to be absolutely sure, could you try reproducing against staging environment e.g. http://meet.staging.livekit.io/ to get server-side logs cc @boks1971