Avoid losing data channel events during transfer

[jan-ivar]

Depending on when an RTCDataChannel is created, its underlying data transport might queue a task with open, message, or close events at any time. If this happens during transfer to a worker, the events might get lost. We need to specify it so this doesn't happen.

A precedent to follow here seems to be MessagePort.

It defines transfer steps to ship its port message queue over dataHolder.[[PortMessageQueue]] , as well as a default virtual unshipped port message queue ahead of transfer.

We should be able to cargo-cult something similar for RTCDataChannel.

[youennf]

Contrary to MessagePort, RTCDataChannel can only be transferred for a limited period of time after being created.
One goal is to limit UA implementation complexity and remove the need to transfer the message queue.

[dontcallmedom-bot]

This issue had an associated resolution in WebRTC July 2025 meeting – 15 July 2025 (Issue #3058: Avoid losing data channel events during transfer):

RESOLUTION: the issue can be closed since no spec change is needed