In Selenoid (unmaintained), how does following a session under /logs/ differ from downloading its saved .log file?

`/logs/` on a session-container grid looks like one feature and is two. Which branch a request lands in explains several baffling results: a download that returns nothing while the test is clearly producing output, a listing that advertises files the same path refuses to serve, and a live stream that works on one deployment and not another. ## The dispatch rule Aerokube's Selenoid, unmaintained by its own README and read here as an open model of a mechanism hosted services implement privately, strips the `/logs/` prefix and looks at what is left: - If a log output directory is configured **and** the remainder is empty or ends in `.log`, the request is handled as a file operation against that directory. - Otherwise the request is handed to a websocket handler that follows a live session. The test is purely syntactic. Nothing looks up whether a session exists before choosing the branch, and nothing looks at the HTTP method until the branch is already chosen. ## The archive branch Inside the file branch there are three behaviours: - `DELETE /logs/<name>.log` removes the file, answering not-found when it is already gone. - `GET /logs/?json` returns the directory as a JSON array of names. - Any other `GET` is served by an ordinary static file server rooted at the output directory, which gives you both the plain listing for `/logs/` and the download for `/logs/<name>.log`. There is a real asymmetry in that list. The listing enumerates **every** file in the directory, but only names ending in `.log` reach the file branch. A build that also writes per-session metadata as JSON into the same directory therefore produces entries visible in the listing but unfetchable through this path: a request for one fails the suffix test and is handed to the websocket handler, which has no idea what to do with it. ## The live branch The other branch opens a websocket and follows the browser's own container output, standard output and standard error together, streaming it until the client disconnects or the session ends. This is what a grid user interface renders in a terminal panel while a test runs. Its prerequisites are different from the archive branch's in both directions: | | live follow | saved file | |---|---|---| | needs an output directory | no | yes | | needs a per-session log capability | no | yes, unless capture is global | | needs a container-backed session | yes | no | | downloadable while the session runs | yes | not under its final name | | carries timestamps | no | yes, in container mode | The container requirement surprises people. When Selenoid runs browser drivers as local processes rather than containers, a session has no container to follow, and the live branch reports it as not found though the session is plainly running. ## Why the saved file is late In container mode the saved log is not streamed as the test proceeds. At session close, and before the browser's container is removed, the server reads that container's accumulated output through the container runtime and copies it into a file in one pass, with timestamps attached. Only then is the file renamed from the random temporary name it was allocated at session start to its final name, which is either the session identifier or whatever the session asked for. Two consequences follow, and both are worth saying out loud in an interview: 1. In container mode there is nothing to download mid-session. A harness that polls for the file while the test runs will poll forever. 2. The final name appears only at the end. The temporary name is a poor handle rather than none: it is random, the session-creation reply never carries it, and only the directory listing reveals it. When Selenoid instead drives bare processes, the shape inverts: the file is created at session start and the driver process writes into it live. That temporary-named file is on disk while the session runs and its name ends in the log extension, so the listing shows it and the archive branch serves it half-written. It is still renamed at close, so the name you would ask for still only becomes valid at the end. ## Reading the same failure two ways Consider a port-logistics container-tracking suite whose shipment-status view intermittently never finishes loading. The two channels answer different questions about it: - The live follow answers "what is the browser saying right now, while it is stuck" — which is the question you have during a reproduction attempt, with a human watching. - The saved file answers "what did the browser say, in order, with timestamps" — which is the question you have the next morning, with nobody watching. A triage design with only the live channel cannot answer the second question, and one with only the archive channel cannot answer the first. They are complements, not alternatives, and the single `/logs/` prefix makes them look like one feature. ## What to verify on an unfamiliar deployment - Fetch the bare listing. If it does not answer as a directory, no output directory is configured and the archive branch does not exist here. - Try a live follow against a known-running session. If it reports the session as not found while the session is demonstrably alive, the deployment is not container-backed.