[flutter_webrtc] Add regression integration tests and fix close() double-call error#1067
[flutter_webrtc] Add regression integration tests and fix close() double-call error#1067seungsoo47 wants to merge 3 commits into
Conversation
Bump flutter_webrtc_tizen to 0.2.3. Calling RTCPeerConnection.close() more than once caused an error on Tizen. The first call removed the connection from the internal map, so the second call could not find it and threw an exception. Fixed by returning success instead of an error when the connection is already closed. The WebRTC spec requires close() to be callable multiple times without error. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Upstream flutter_webrtc has no integration tests at v1.5.2, so Tizen-specific regression tests were authored from the public API surface. Added 8 test cases covering the API surface that works without camera hardware (RTCPeerConnection and RTCDataChannel); camera-dependent APIs such as getUserMedia are excluded because they require physical camera hardware that is not available on the test target. Tests added: - RTCPeerConnection: creates with empty ice servers - RTCPeerConnection: createOffer returns valid SDP - RTCPeerConnection: setLocalDescription succeeds - RTCPeerConnection: createAnswer returns valid SDP - RTCPeerConnection: close is idempotent - RTCDataChannel: createDataChannel returns channel with correct label - RTCDataChannel: loopback text message exchange - RTCDataChannel: loopback binary message exchange The "close is idempotent" test required fixing the native plugin (see preceding commit). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the flutter_webrtc_tizen plugin to version 0.2.3, making RTCPeerConnection.close() idempotent by returning success instead of an error when the peer connection is already null. It also introduces integration tests for peer connections and data channels, along with the necessary test driver and dependency updates. The reviewer suggests improving the robustness of the loopback tests by checking the data channel state synchronously before registering listeners, rather than relying on timeouts with empty handlers.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Register the onDataChannelState listener only after confirming the channel isn't already open, per Gemini Code Assist review on PR flutter-tizen#1067. The previous code could miss the open event if it fired before the listener was attached, silently waiting out the full 10s timeout via an empty onTimeout handler instead of failing when a channel never opens.
1 participant
RTCPeerConnection.close()throwing on Tizen when called more than once (the first call removed the connection from the internal map, so the second call couldn't find it). Now returns success instead of an error, per the WebRTC spec.RTCPeerConnection/RTCDataChannel(upstream flutter_webrtc has no integration tests at v1.5.2). Camera-dependent APIs likegetUserMediaare excluded — no camera hardware on the test target.