[webrtc-pc] Possibly racy replaceTrack()

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== Possibly racy replaceTrack() ==
Roughly speaking, replaceTrack() does this:
```
In parallel:
  Determine if negotiation is needed, if it is, reject promise.
  Otherwise queue a task that runs the following steps:
    Set track and resolve promise (unless pc is closed).
```

I think there's two issues with determining if negotiation is needed in parallel and then queuing a task to complete the operation:
1. It's possible that in-between checking that negotiation was not needed and running the task, the sender is modified such that negotiation would indeed be needed. The track is replaced even though it can't be sent seamlessly. Assuming we don't get encoding errors, how will the other endpoint react?
2. Performing the "is negotiation needed" check in parallel means it is racy, we don't know if it will occur before or after removeTrack(), for instance:
```
let promise = sender.replaceTrack(track);
// Will "is negotiation needed" happen before or after removeTrack()?
pc.removeTrack(sender);
```
I can see this code snippet resolving or rejecting the `promise` depending on a race. Do we care?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1728 using your GitHub account

Received on Tuesday, 9 January 2018 10:24:48 UTC