A hosted browser provider is holding your new-session request open — what bounds that wait?

## Read the control flow, do not assume a deadline The instinct on hearing "the request is queued" is that something on the far side is counting down and will eventually give up. That is a product-by-product fact, and it is checkable in the open implementations. Selenoid, unmaintained per its own README, routes a new-session request through a handler that blocks on a `select` with exactly two cases: a run slot becoming free, or the request's context being cancelled. There is no third case, no timer, and its HTTP server is constructed with no read, write or idle timeout of its own. Selenoid's own usage-statistics documentation states it directly: queued requests "just block and continue to wait". The only thing on that side that ends the wait, other than capacity appearing, is the client hanging up — which the handler handles explicitly, draining its queued counter and logging the disconnect rather than leaking it. Selenium Grid takes the other route: it bounds the hold with a server-side request deadline and answers `session not created` when the deadline passes. Both are legitimate; the point is that the behaviour is a per-product choice, never a protocol guarantee. ## What is actually being consumed While a request is held: - **No browser exists yet.** The session has not been created, so a per-session meter has no session to attach to; whether a provider nevertheless counts from admission is something to establish with a deliberately over-concurrent probe rather than to assume. - **Your runner is fully occupied.** The CI machine sits in a blocking call, holding its container, its cache and its place in your own pipeline's concurrency — money on a rented machine, forgone work on one you own. - **The job budget is being spent.** A merge-gating smoke suite for a ticketing site that waits for a slot is consuming the same minutes it would have spent testing. - **The signal is suppressed.** Because the wait ends in success, saturation never surfaces as a failure; it surfaces as a slow week. That asymmetry is the reason a wait feels free and is not. It is cheap where you are watching and expensive where you are not. ## Put the deadline where you control it Since the far side may never give up, the client must. In Selenium's Java bindings the knob is `ClientConfig.readTimeout(Duration)`, handed to the builder: ```java ClientConfig config = ClientConfig.defaultConfig() .baseUri(URI.create(System.getenv("TICKETS_GRID_URL"))) .readTimeout(Duration.ofSeconds(Long.parseLong(System.getenv("TICKETS_SLOT_WAIT_SECONDS")))); ``` A few rules make that deadline useful rather than decorative: 1. **Size it under the job's budget, not over it.** A read timeout longer than the pipeline step's own limit is never reached; the step is killed first and you lose the diagnosis. 2. **Make it a separate value from the command timeout.** Waiting for admission and waiting for a slow page are different failures and want different limits. 3. **Log the elapsed construction time on every session, successful or not.** The distribution of that number is the saturation signal; the timeout is only the safety net. 4. **Do not set it to something enormous "to be safe".** An unbounded client against an unbounded server is a hang, and a hang in CI is the most expensive failure mode there is. ## Instrumenting the wait The measurement you want is the gap between "the suite asked for a session" and "the session existed", per lane, over time. A rising floor is saturation; a fat tail is contention with another consumer of the same account. Where the grid is yours to query, read its own counters instead of inferring: Selenoid publishes a state document with `queued` alongside `total`, `used` and `pending`, so the depth of the queue is a fact rather than a guess. Two further observations that come out of the same code and matter operationally: - A client that gives up is **accounted for**, not leaked — the disconnect path drains the queued counter. So aggressive client-side deadlines do not corrupt the service's own view of demand. - The queue depth itself is unbounded in that implementation; only the simultaneous-run limit is a cap. A service can therefore accumulate an arbitrarily deep backlog of patient clients while reporting a perfectly healthy set of running sessions. ## The interview answer Say plainly that nothing obliges a remote service to bound the hold, cite that at least one readable implementation bounds it only by client disconnect while another bounds it by a server deadline, and then move the responsibility to where it always sits: the client owns its own patience because it owns the socket. Add that the wait certainly costs runner wall-clock, whatever the far side's meter does with it, which is why it hides so well, and that the fix for chronic waiting is admission control — asking for fewer sessions at once — rather than a longer timeout. A candidate who answers "the provider will time it out" has assumed a feature.