[PR #452] [MERGED] fix(lobby): deliver device unplug events to the lobby container #477

New issue

Closed

opened 2026-10-15 13:00:52 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:52 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/452
Author: @kmreisi
Created: 7/2/2026
Status: ✅ Merged
Merged: 7/2/2026
Merged by: @ABeltramo

Base: stable ← Head: fix/lobby-hotplug-reconnect

📝 Commits (1)

a9d7c60 fix(lobby): deliver device unplug events to the lobby container

📊 Changes

2 files changed (+44 additions, -2 deletions)

View changed files

📝 src/moonlight-server/sessions/lobbies.cpp (+2 -2)
📝 tests/testWolfAPI.cpp (+42 -0)

📄 Description

Problem

Hot-plugging a controller (disconnect then reconnect) while a Moonlight session is inside a lobby app (e.g. Steam) doesn't reach the app — the reconnected pad never shows up. A plain Wolf-UI session is fine; it only breaks once the session has joined a lobby.

Cause

The lobby's UnplugDeviceEvent handler re-fires the event to the lobby's runner as a bare events::UnplugDeviceEvent:

app_state->event_bus->fire_event(
    events::UnplugDeviceEvent{.session_id = lobby->id, ...});

Every handler registers for immer::box<events::UnplugDeviceEvent>, and dp::event_bus keys handlers by typeid(EventType). So the unboxed event matches no handler and is silently dropped — the lobby container never receives the remove.

The stale device node then makes the next replug fail at mknod ... File exists, and since the plug command is mknod ... && fake-udev, the &&-chained ADD uevent never fires, so the app never sees the reconnect.

The sibling paths (plug relay, join, leave) all box the event; this one didn't — it has been this way since lobbies were introduced.

Fix

Box the relayed event, matching the other paths. Includes a regression test that drives the relay through setup_lobbies_handlers (no compositor required).

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/452 **Author:** [@kmreisi](https://github.com/kmreisi) **Created:** 7/2/2026 **Status:** ✅ Merged **Merged:** 7/2/2026 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `stable` ← **Head:** `fix/lobby-hotplug-reconnect` --- ### 📝 Commits (1) - [`a9d7c60`](https://github.com/games-on-whales/wolf/commit/a9d7c60a033b06b991928840a953ce6ce479e69c) fix(lobby): deliver device unplug events to the lobby container ### 📊 Changes **2 files changed** (+44 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-server/sessions/lobbies.cpp` (+2 -2) 📝 `tests/testWolfAPI.cpp` (+42 -0) </details> ### 📄 Description ## Problem Hot-plugging a controller (disconnect then reconnect) while a Moonlight session is inside a lobby app (e.g. Steam) doesn't reach the app — the reconnected pad never shows up. A plain Wolf-UI session is fine; it only breaks once the session has joined a lobby. ## Cause The lobby's `UnplugDeviceEvent` handler re-fires the event to the lobby's runner as a **bare** `events::UnplugDeviceEvent`: ```cpp app_state->event_bus->fire_event( events::UnplugDeviceEvent{.session_id = lobby->id, ...}); ``` Every handler registers for `immer::box<events::UnplugDeviceEvent>`, and `dp::event_bus` keys handlers by `typeid(EventType)`. So the unboxed event matches no handler and is silently dropped — the lobby container never receives the remove. The stale device node then makes the next replug fail at `mknod ... File exists`, and since the plug command is `mknod ... && fake-udev`, the `&&`-chained ADD uevent never fires, so the app never sees the reconnect. The sibling paths (plug relay, join, leave) all box the event; this one didn't — it has been this way since lobbies were introduced. ## Fix Box the relayed event, matching the other paths. Includes a regression test that drives the relay through `setup_lobbies_handlers` (no compositor required). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:52 +00:00