Why does a hung test on a remote browser grid keep consuming despite an idle timeout?

## Two different clocks A remote fleet's session timeout and a hung test measure different things, and confusing them is the mistake this question exists to catch. - **The fleet's clock measures silence.** It is an *inactivity* timeout: it fires when no command has arrived for that session for a while, and its job is to release a slot whose client has evidently gone away. - **Your clock measures progress.** A test is hung when it is getting nowhere, which has nothing to do with whether it is sending traffic. The open implementations state the first clock plainly. Selenium Grid's node flag `--session-timeout` is documented as automatically killing a session that has had no activity for that long, and explicitly as releasing the slot for other tests; `docker-selenium` surfaces that same setting to its images as `SE_NODE_SESSION_TIMEOUT`. Selenoid — unmaintained by its own README — re-arms each session's idle timer on **every request its proxy forwards**, and only a delete removes the session and releases its run slot. A hosted provider will have something of the same shape, but its window and its exact rule are facts to establish with the vendor rather than carried over from an open project. ## The two hang shapes | hang shape | what the wire shows | what the reaper does | what your client sees | |---|---|---|---| | a polling wait for a condition that never becomes true | a command on every poll | nothing — the timer keeps resetting | the case runs on until one of your own timeouts fires | | a block inside a long-running command with no timeout | silence | fires, deletes the session, releases the slot | the next command fails as an unknown session | Take the planning-application tracker suite. A case submits an application and waits for its status to read *validated*. The status never changes, because the background job that would have changed it did not run. The wait polls: it asks for the status element, sleeps briefly, asks again. Each ask is a command, each command re-arms the fleet's idle timer, and the session therefore looks perfectly healthy from the far side while making no progress whatever. It holds its slot and keeps consuming until something of yours stops it. The other shape is often misread. A case calls a navigation, or asks the browser to evaluate a long script, with no client-side timeout on the call. Nothing goes out for the duration, the reaper eventually fires, the session is deleted and the slot released — and then your next command fails with an unknown-session error long after the last step that worked. Read that as a bound firing, not as a flaky product. ## Where the bound has to come from Since the fleet's clock catches only the quiet shape, the bound for the noisy one has to be yours. Layer it, each level smaller than the one above: 1. **A timeout on the individual call**, so no command can block for an unbounded time. 2. **A timeout on the case**, enforced by something *outside* the case — the runner, or a watchdog that can interrupt or kill it. A case blocked inside a network call cannot check its own clock, and in-case guards run only between steps, which is exactly where a hung case is not. 3. **A budget on the job**, so a pathological run ends even if the levels beneath it fail. What a blocking pipeline invocation should promise inside its budget belongs to pipeline wiring; here it is only the outermost backstop. Two more belong in that stack and are easy to leave out: - **Cap retries.** A bounded wait inside an unbounded retry loop is unbounded again, and a retry that reopens a session multiplies the consumption rather than adding to it. - **Make the case timeout close the session too.** A case abandoned without a close hands the problem back to the reaper, which will take it only once the case has actually gone quiet. ## What this does to consumption - An unbounded wait is an open-ended commitment on a metered fleet, and it survives review because waiting for a condition reads as patience rather than as a blank cheque. - It is **not** the only construct with that property: an unbounded retry loop, and a test that re-navigates forever, do the same thing. - Some fleets impose a **maximum total session length** as well as an inactivity timeout. The two are different rules, and a total-length cap would catch the polling hang the inactivity timeout misses — but whether a given provider enforces one is a vendor fact to establish before you lean on it. ## Getting it wrong in the other direction The tempting fix on a fleet you operate yourself is to shorten the inactivity timeout. It does catch abandoned sessions sooner. It still does nothing for the polling hang, and it starts killing legitimate sessions whose tests have a genuinely quiet stretch — a long upload, a slow report generation, a deliberate wait on a background job. Shortening a reaper is a blunt instrument aimed at a different problem; the bound on a runaway case belongs in the suite that runs it.