[GH-ISSUE #19] Re-launching an app with a running lobby spawns a second instance that dies in <1s (stream drops) instead of re-joining #14

New issue

Open

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

bsakaguchi commented

2026-10-15 13:01:26 +00:00

Owner

Originally created by @TrafficDemotion on GitHub (Oct 7, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf-ui/issues/19

What happens

When an app (e.g. Steam) already has a running lobby for a profile, clicking the app again in the Wolf UI creates a second lobby/container instead of joining the existing one. The second container is killed within ~0.7 s (same profile home — Steam single-instance lock), Wolf then stops the new lobby, and the client stream drops right after connecting. From the user's point of view: "I click Steam and I get kicked out" (looks like a crash).

Why it's confusing

Lobbies are persistent (stop_when_everyone_leaves=false, see #17): after disconnecting the stream the container is still running, but nothing suggests re-joining it.
The new stream drops ~1 s after connecting, so there is no chance for the user to understand what happened.
Re-joining the existing lobby works fine (it is listed on the first page) — but only if the user knows to do that.

Reproduction

Wolf UI -> profile user -> click Steam -> lobby A + container A start (stream works fine).
Close the stream (without clicking Stop). Container A keeps running (as designed).
Open the profile again and click Steam (instead of re-joining lobby A).
Lobby B + container B are created; container B exits within ~0.7 s; lobby B is stopped; the client is kicked back.

Wolf logs:

[DOCKER] Starting container: /WolfSteam_<id-B>
Stopped container: /WolfSteam_<id-B>        # ~0.7 s later
[LOBBY] stopping lobby <id-B>

Expected behavior

Clicking an app that already has a running lobby should either:

join the existing lobby, or
ask the user ("an instance is already running — re-join it / stop it and start a new one / cancel").

Suggested fix

App.cs always goes through CreateLobby -> JoinLobby. Before creating, query GET /api/v1/lobbies and if a lobby for the same profile + app already exists, join that one instead. There is already a TODO for exactly this in src/Scenes/Main/Body/Apps/App.cs:332:

//TODO: check if user already has a open singleplayer lobby for the chosen ap or folder and if yes re-join.

Environment

wolf-ui: ghcr.io/games-on-whales/wolf-ui:main (image built 2026-06-24)
wolf: ghcr.io/games-on-whales/wolf:stable (image built 2026-09-29)
app image: ghcr.io/games-on-whales/steam:edge
Ubuntu 25.04 VM, NVIDIA RTX 5060 (zero-copy pipeline), clients: Moonlight-qt 6.1.0

Note: this only affects re-launching the same app on the same profile; launching apps from different profiles in parallel works fine (cross-profile lobbies coexist).

Originally created by @TrafficDemotion on GitHub (Oct 7, 2026). Original GitHub issue: https://github.com/games-on-whales/wolf-ui/issues/19 **What happens** When an app (e.g. Steam) already has a running lobby for a profile, clicking the app again in the Wolf UI creates **a second lobby/container** instead of joining the existing one. The second container is killed within **~0.7 s** (same profile home — Steam single-instance lock), Wolf then stops the new lobby, and the client stream drops right after connecting. From the user's point of view: "I click Steam and I get kicked out" (looks like a crash). **Why it's confusing** - Lobbies are persistent (`stop_when_everyone_leaves=false`, see #17): after disconnecting the stream the container is still running, but nothing suggests re-joining it. - The new stream drops ~1 s after connecting, so there is no chance for the user to understand what happened. - Re-joining the existing lobby works fine (it is listed on the first page) — but only if the user knows to do that. **Reproduction** 1. Wolf UI -> profile `user` -> click **Steam** -> lobby A + container A start (stream works fine). 2. Close the stream (without clicking Stop). Container A keeps running (as designed). 3. Open the profile again and click **Steam** (instead of re-joining lobby A). 4. Lobby B + container B are created; container B exits within ~0.7 s; lobby B is stopped; the client is kicked back. Wolf logs: ``` [DOCKER] Starting container: /WolfSteam_<id-B> Stopped container: /WolfSteam_<id-B> # ~0.7 s later [LOBBY] stopping lobby <id-B> ``` **Expected behavior** Clicking an app that already has a running lobby should either: - **join** the existing lobby, or - ask the user ("an instance is already running — re-join it / stop it and start a new one / cancel"). **Suggested fix** `App.cs` always goes through CreateLobby -> JoinLobby. Before creating, query `GET /api/v1/lobbies` and if a lobby for the same profile + app already exists, join that one instead. There is already a TODO for exactly this in `src/Scenes/Main/Body/Apps/App.cs:332`: > `//TODO: check if user already has a open singleplayer lobby for the chosen ap or folder and if yes re-join.` **Environment** - wolf-ui: `ghcr.io/games-on-whales/wolf-ui:main` (image built 2026-06-24) - wolf: `ghcr.io/games-on-whales/wolf:stable` (image built 2026-09-29) - app image: `ghcr.io/games-on-whales/steam:edge` - Ubuntu 25.04 VM, NVIDIA RTX 5060 (zero-copy pipeline), clients: Moonlight-qt 6.1.0 Note: this only affects re-launching the **same app on the same profile**; launching apps from different profiles in parallel works fine (cross-profile lobbies coexist).

bsakaguchi referenced this issue

2026-10-15 13:01:29 +00:00

[PR #15] [MERGED] feat: added Env var to allow changing Wolf-UI startup parameter. closes #14 #18