RTCDataChannel: Ignore send failures
There is a possible race between send() and close events between the
WebRTC and Chrome layers.
In this case, the Chrome layer will try to send() over a data channel
with a pending remote close event. It is safe to ignore this error.
Queued data on a data channel is discarded on remote close(), so the
observable behaviour is correct.
Bug: 1260845, 1267579
Change-Id: I0194102d91293979caf3092d6deb61a00c82d6e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3268746
Commit-Queue: Florent Castelli <orphis@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/main@{#940132}
diff --git a/third_party/blink/renderer/modules/peerconnection/rtc_data_channel.cc b/third_party/blink/renderer/modules/peerconnection/rtc_data_channel.cc
index 3b65168..fdc0a91 100644
--- a/third_party/blink/renderer/modules/peerconnection/rtc_data_channel.cc
+++ b/third_party/blink/renderer/modules/peerconnection/rtc_data_channel.cc
@@ -188,13 +188,19 @@
// signaling thread to resolve from the JS main thread. So we make sure that
// channel->Send() doesn't fail by replicating the checks in the Blink layer.
// The possible failures per the spec are:
- // - Channel not in open state (checked in every Send() implementation).
+ // - Channel not in open state. Although we check the state in each Send()
+ // implementation, it's possible to have a short race between the WebRTC state
+ // and the Chrome state, i.e. sending while a remote close event is pending.
+ // In this case, it's safe to ignore send failures.
// - Data longer than the transport maxMessageSize (not yet implemented in
// WebRTC or Blink).
// - Send Buffers full (buffered amount accounting in Blink layer to check for
// it).
bool result = channel->Send(data_buffer);
- CHECK(result);
+ if (!result) {
+ // TODO(orphis): Add collect UMA stats about failure.
+ LOG(ERROR) << "Send failed, channel state: " << channel->state();
+ }
}
} // namespace