GUI Room example app. - #600

🟡 toggle_test_video/toggle_test_audio permanently stuck after task completes due to error

The toggle methods use not self._test_video_task.cancelled() to decide whether the task is still active. asyncio.run_coroutine_threadsafe returns a concurrent.futures.Future. After the coroutine completes due to an error (e.g., publish fails because room disconnected), the future is in FINISHED state — cancelled() returns False and done() returns True. Subsequent calls to toggle_test_video() always enter the "stop" branch at line 169, call cancel() on the already-finished future (which returns False and does nothing), and return False. The user can never start a new test video/audio until reconnecting. The fix is to use .done() instead of .cancelled() to check if the task has already completed.

Was this helpful? React with 👍 or 👎 to provide feedback.

🟡 toggle_test_audio has same stuck-after-error bug as toggle_test_video

Same issue as the video toggle: toggle_test_audio uses not self._test_audio_task.cancelled() at line 233, which becomes permanently stuck after the audio publishing task completes due to an error. Should use .done() instead.

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 _on_local_track_unpublished unconditionally removes video stream regardless of track kind

When any local track is unpublished (including audio), the handler at line 393 unconditionally pops from self._video_streams for the local participant identity. If the user has both test video and test audio publishing, stopping the audio track triggers _on_local_track_unpublished, which incorrectly closes the video stream. Compare with _on_local_track_published at examples/wxpy_room/wxpy_room.py:376 which correctly checks track.kind == rtc.TrackKind.KIND_VIDEO. The unpublish handler should similarly check publication.kind (available via TrackPublication.kind at livekit-rtc/livekit/rtc/track_publication.py:44) before removing the video stream.

Was this helpful? React with 👍 or 👎 to provide feedback.

🟡 Event loop thread leaked forever on connection error

When _async_connect catches a connection error at line 311, it posts an "error" state but the coroutine returns normally. The caller _run_loop at line 276 then calls self.loop.run_forever(), which blocks forever since nothing ever calls loop.stop(). The wx-side error handler at line 1111 creates a new RoomManager, orphaning the old thread and event loop. Each failed connection attempt leaks a daemon thread.

Was this helpful? React with 👍 or 👎 to provide feedback.