# FAF self-host stalls before `HostGame`

## Summary

FAF launches Supreme Commander: Forged Alliance successfully, but both joining and self-hosting remain on **Connecting** indefinitely. The game and ICE adapter reach `GameState Lobby`; the FAF client receives and forwards that state, but the ICE adapter never receives the subsequent `HostGame`, `JoinGame`, or peer-connect instruction.

This occurs on Linux with FAF clients `2026.7.0`, `2026.7.1`, and—most importantly—the previously working `2026.1.0` client.

## Strong working/failing comparison

- **Working:** game `27493928`, self-hosted by `Visvires` on 2026-07-27. The attached completed replay identifies lobby version `dfaf-2026.1.0`.
- **Failing:** game `27591705`, self-hosted by `Visvires` on 2026-08-11 using the same installed `2026.1.0` client and its original JDK `25.0.1+8`.
- In the failed attempt, the game reports `GameState Idle` and then `GameState Lobby`. No `onHostGame` or `HostGame` follows.

Because the exact client version that successfully hosted on July 27 now reproduces the failure, this does not appear to be a regression caused solely by updating the local client to `2026.7.x`.

Inspection of `FAForever/server` shows that the expected server path is deterministic: receiving host `GameState Idle` sets the player state to `HOSTING`, and receiving `GameState Lobby` then immediately calls `send_HostGame`. The repository includes a unit test for this behavior, and there has been no recent change to `server/gameconnection.py`. Therefore, the key missing evidence is whether production actually receives the client's game-targeted `GameState` message over the lobby WebSocket and, if it does, what player/game state is associated with it. The local log proves that the ICE adapter delivered `GameState Lobby` to the Java callback; it does not by itself prove receipt by the server.

## Environment

- User: `Visvires` (FAF UID `80528`)
- OS: Nobara Linux
- faf-linux installation
- Failed comparison client: `2026.1.0`
- Java for failed comparison: `25.0.1+8`
- Game ID: `27591705`
- Time: approximately 2026-08-11 01:07 CDT (America/Chicago)

The same symptom was previously reproduced over wired Ethernet and a phone hotspot. The local firewall permits FAF's observed ports. Offline launch works normally. The game executable, Wine/Proton wrapper, writable paths, local ICE connection, and launch process have therefore already been checked.

## Attached files

- `client.log` — client log containing the `2026.1.0` session and failed host attempt.
- `ice-adapter.log` — ICE log containing the failed game `27591705` flow.
- `game_27591705.log` — Forged Alliance log for the failed attempt.
- `27493928-Visvires.fafreplay` — completed July 27 self-host replay showing the known-good `dfaf-2026.1.0` case.

The latest `advanced-ice-adapter.log` predates game `27591705`, so it is intentionally not included as though it came from this reproduction. Prior advanced logs show the same stopping point but add no peer-negotiation data because negotiation never begins.

## Requested investigation

Please check production lobby-server/WebSocket logs for FAF user `80528` and game `27591705`:

1. Did the server receive `GameState Idle` and `GameState Lobby` with `target: game`?
2. Was the associated player state `HOSTING`, and was the player still the game's host?
3. Did `GameConnection._handle_lobby_state()` call `send_HostGame`?
4. If it did, was the resulting targeted message successfully written back through the WebSocket transport?

Game `27493928` is the useful known-good comparison.

## Sanitization

Copied text logs were sanitized for OAuth/JWT access tokens and email addresses. The replacements are marked `[REDACTED_ACCESS_TOKEN]` and `[REDACTED_EMAIL]`. Game IDs, FAF username/UID, timestamps, class names, and diagnostic messages were preserved.