Streaming: log session lifecycles and why streamers fail #7

2026-10-14T00:52:16-07:00

dejima-agent commented

2026-10-14 00:52:16 -07:00

Summary generated by LLM agent

Makes streaming failures visible. Until now the session manager logged only "Session manager started". A streamer that crashed on start deleted itself (AutoRemove), and the player waited out a 60-second timeout with nothing in any log to say why.

Changes

Lifecycle logs. Each session logs a line when it's:
- created, with the game and display size;
- ready, with how long startup took;
- removed, with the reason: nobody connected, player left, failed to start, or shutting down.
Failing fast. While waiting for the streamer, the session manager also checks the container's state. If it exits, the start fails at once with its exit code, instead of after 60 seconds.
The crash's own output. On a failed start, the container's last 30 log lines are added to the error and logged. Containers are no longer auto-removed, so that output survives until teardown. Teardown always removes the container, and leftovers from a previous run are still cleared at startup.
A clean status. A failed start now reaches the app as 502 game failed to start, rather than a generic 500, which also printed a duplicate stack trace.
Docs. The streaming guide's troubleshooting section explains what the log shows.

Testing

Session manager tests: 21 pass, 6 new:

Readiness wait: it resolves once the streamer answers, fails immediately when the container exits, and gives up at the timeout.
Log decoding: Docker's framed log output and plain text both decode.
Lifecycle logging: a session logs creation, readiness and removal.
Failed start: it's reported as 502 and logged with the streamer's output, and the container is removed.

The real Docker paths (inspect, logs) aren't exercised here, since the sandbox has no Docker. Starting a streamed game on flashbox after deploying will show the new log lines.

**Summary generated by LLM agent** Makes streaming failures visible. Until now the session manager logged only "Session manager started". A streamer that crashed on start deleted itself (`AutoRemove`), and the player waited out a 60-second timeout with nothing in any log to say why. ## Changes - **Lifecycle logs.** Each session logs a line when it's: - created, with the game and display size; - ready, with how long startup took; - removed, with the reason: nobody connected, player left, failed to start, or shutting down. - **Failing fast.** While waiting for the streamer, the session manager also checks the container's state. If it exits, the start fails at once with its exit code, instead of after 60 seconds. - **The crash's own output.** On a failed start, the container's last 30 log lines are added to the error and logged. Containers are no longer auto-removed, so that output survives until teardown. Teardown always removes the container, and leftovers from a previous run are still cleared at startup. - **A clean status.** A failed start now reaches the app as `502 game failed to start`, rather than a generic 500, which also printed a duplicate stack trace. - **Docs.** The streaming guide's troubleshooting section explains what the log shows. ## Testing Session manager tests: 21 pass, 6 new: - **Readiness wait:** it resolves once the streamer answers, fails immediately when the container exits, and gives up at the timeout. - **Log decoding:** Docker's framed log output and plain text both decode. - **Lifecycle logging:** a session logs creation, readiness and removal. - **Failed start:** it's reported as 502 and logged with the streamer's output, and the container is removed. The real Docker paths (`inspect`, `logs`) aren't exercised here, since the sandbox has no Docker. Starting a streamed game on flashbox after deploying will show the new log lines.

dejima-agent added 1 commit 2026-10-14 00:52:17 -07:00

feat(streaming): log session lifecycles and why streamers fail 9144395201

The session manager logs each session's creation, readiness time and
removal with its reason. A streamer that exits during startup now fails
the start at once instead of after 60 seconds, and the log carries its
exit code and last output; containers are no longer auto-removed, so
that output survives until teardown. A failed start reaches the app as
a 502.

branderson approved these changes 2026-10-14 16:02:23 -07:00

branderson merged commit c5b1f750bc into main

2026-10-14 16:02:28 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: branderson/dotcom-arcade#7