"Track name is duplicated" error when unpublishing/publishing track during reconnection

[jsdream]

trafficstars

• [x] I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
• [x] I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
• [x] I verified that the Quickstart application works in my environment.
• [x] I am not sharing any Personally Identifiable Information (PII) or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Expected behavior:

Unpublishing and then publishing local track while the connection is lost should not cause any issues upon reconnection.

Actual behavior:

In our case, if we unpublish an audio track and publish a new one with the same name while there is a reconnection, upon successful reconnection we'll get a "Track name is duplicated" error.

The main problem here seems to be is that we can't reliably know either track was actually unpublished in the Twilio backend or not, as there is no 'trackUnpublished' event for the local participant. These issues I think are related: https://github.com/twilio/twilio-video.js/pull/657 and https://github.com/twilio/twilio-video.js/issues/1007.

In our setup, in order to mute participants, we completely unpublish the audio track and then republish it when the participant unmutes. So if a participant mutes/unmutes while their connection is lost they will get a "Track name is duplicated" error after their connection eventually restored.

To summarize, I think the problem is the following: when calling localParticipant.unpublishTrack it always removes track locally without taking into account a response from the backend, and then calling localParticipant.publishTrack causes the "Track name is duplicated" error as the previous track was not really unpublished, although local state thinks so.

Also, the initial idea how to fix this was to disable the 'mute' button when Twilio room is in 'reconnecting' state, but this doesn't fix the problem completely as Twilio room does not transition to the 'reconnecting' state immediately after the connection is lost, thus leaving the room for the issue to occur.

Software versions:

• [x] Browser(s): Chrome 86.0.4240.75
• [x] Operating System: Windows 10
• [x] twilio-video.js: 2.7.2
• [x] Third-party libraries (e.g., Angular, React, etc.): Angular

[jsdream]

Update:

It turns out that the track is actually being unpublished after the reconnection, it's just a race condition with the localParticipant.publishTrack call.

So, for now, we ended up with such workaround:

public async publishLocalTrackWithWorkaroundForTrackNameIsDuplicatedError (track: LocalTrack) {
    try {
        await this.currentCall.twilioRoom.localParticipant.publishTrack(track);
    }
    catch (err) {
        if (err && err.code === 53304) {
            await new Promise((resolve, reject) => {
                setTimeout(async () => {
                    try {
                        this.Logger.warn('Attempt to workaround "Track name is duplicated" error');
                        await this.currentCall.twilioRoom.localParticipant.publishTrack(track);
                        resolve();
                    }
                    catch (err) {
                        reject(err);
                    }
                }, 1000);
            });

        }
        else {
            throw err;
        }
    }
}

[darrenmhill]

Is anyone able to respond to this one please? This is regularly impacting a number of calls and is having a real business impact.

[makarandp0]

Thank you for reporting this issue and detailed explanation @jsdream. Yes this looks like a race condition that need to be handled by the SDK. I have filed an internal bug to rack this issue (JSDK-3032)

@darrenmhill - Does the workaround suggested by @jsdream not work in your case?

Thanks, Makarand

[jsdream]

Thanks for that @makarandp0!

Looking forward to the proper fix within the SDK.

[darrenmhill]

Thank you for reporting this issue and detailed explanation @jsdream. Yes this looks like a race condition that need to be handled by the SDK. I have filed an internal bug to rack this issue (JSDK-3032)

@darrenmhill - Does the workaround suggested by @jsdream not work in your case?

Thanks, Makarand

We have this in place right now, but have not yet explicitly tested it under these conditions.

[darrenmhill]

Any update on this one please? I think the workaround is working ok, but ideally we'd like a native fix for this.

[grant-with]

This race condition causes some headaches for us, but we've worked around it by appending a random UUID to our track names and updating our track name checking logic to use trackName.startsWith('camera'), etc instead of doing a strict comparison.

That does mean that a user can briefly have 2 "camera" tracks at once, but this doesn't end up being a problem in practice.

[tmb]

Is there an update here? We're running into this error with React Hot Reload during dev — workable but quite annoying.