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