Result Attribution

## The session is not yours to keep A test that creates a browser session on a rented fleet gets back a handle to something running on somebody else's machine, under that machine's rules. Your harness can end the session deliberately. So can the far side, and it will do so for its own reasons - freeing capacity, enforcing a limit, recovering a host - none of which involve your test's progress. This is not unique to rented infrastructure. A grid you run yourself does it too, which is why the open implementations are the clearest place to see the shape: - **Selenium Grid** carries a node flag `--session-timeout`, documented as automatically killing a session that has had no activity for that period, explicitly in order to release the slot for other tests. - **docker-selenium** surfaces that same node setting as the environment variable `SE_NODE_SESSION_TIMEOUT`. - **Selenoid**, which declares itself unmaintained in its own README, has a server-side `-timeout` flag described as a session idle timeout, and its proxy cancels and re-arms the per-session timer on each request it forwards. What changes on a rented fleet is not the mechanism but the ownership: the value was chosen by somebody else, you may not be able to read it, and you may not be able to change it. ## The ways a session ends without you 1. **Inactivity.** No command has arrived for long enough, so the remote end reaps the session and frees the slot. 2. **Total length.** A limit on how long a session may live, applied regardless of how busy it has been. 3. **Your own side hanging up.** The harness crashes, the pipeline job is cancelled, the machine running the test disappears, or the connection drops. 4. **The fleet reclaiming the machine.** A host is drained, restarted or found unhealthy, and the sessions on it go with it. Do not assert which of these a provider does, when its timer fires, or what it logs internally. You cannot see any of it; you can only observe the symptom and establish the correlation. ## Idle means quiet on the wire, not idle in your process This is the part that catches people. An inactivity timer counts **requests received**, not effort expended. A test that is working very hard - building a large booking fixture, waiting on a slow external system, sitting on a breakpoint, sleeping in its own process - is, from the remote end's point of view, indistinguishable from a test that has stopped existing. Selenoid, unmaintained by its own README, shows the mechanism plainly: its timer is reset on each forwarded request, so anything that does not travel to the browser does not count as life. The inverse also holds, and it is why an idle timeout is not a safety net. A case stuck in a polling wait is sending commands continuously, so it looks perfectly alive while making no progress at all. ## What you see, and what you must establish The visible failure is almost never self-describing. The next command after the session ends fails because the remote end no longer recognises the identifier, which the W3C WebDriver specification names `invalid session id`. That error names the symptom - the session is gone - and says nothing about why, when, or on whose initiative. | observation | what it points at | |---|---| | a long quiet gap on the wire before the failure | an inactivity reap | | failure at a similar elapsed time from session start, whatever the step | a limit on session length | | your own process died or the job was cancelled first | your side, not theirs | | several concurrent sessions ending together | the machine or the route, not one test | So instrument for attribution rather than hoping the error explains itself: - Record the session identifier the remote end returned, and log it with every result. - Timestamp every command, and on failure report both the elapsed time since the last successful command and the elapsed time since session start. Those two values alone separate the first two causes. - Log whether your own process and connection were healthy at the moment of failure, so your side can be ruled in or out without argument. ## Cleanup is something you request, not something you assume A dropped connection is not a teardown. Selenoid, unmaintained by its own README, is explicit about this in its behaviour: its proxy error handler logs the client disconnect and returns a gateway error without removing the session, which then ends later on its own timer. Treat every rented session the same way: end it explicitly in a teardown block that runs even when the test throws, and never rely on the far side noticing you have gone. Two habits follow directly. - **Quit the session in a guaranteed-teardown path**, not at the end of the happy path. - **Keep the wire alive only when that is honest.** Do not invent keepalive commands to dodge a reaper while your test is genuinely stuck; that turns a session that would have ended into one that hangs, and hides the real defect. This is about a session that was created and then taken away mid-run. A request never granted in the first place, for want of free capacity, is a different situation with a different signature.