On a long-lived shared runner, how far do you go beyond driver.quit() to stop Selenium sessions accumulating?

## What quit() covers, and where its guarantee stops `driver.quit()` is the only clean path out of a session. It sends **Delete Session**, so the remote end closes every window the session owns, terminates the browser, and discards the session's state including the **temporary profile directory** the driver generated; on a Grid the node frees the slot; on a local run the client stops the driver executable it launched. When `quit()` runs, nothing is left behind. The whole question at this level is what happens on the runs where it does not run - because `quit()` is code, and code needs a live process to execute it. On a laptop that is a nuisance. On a runner that stays up for weeks and is shared between jobs, the residue is cumulative, and eventually it is the thing that fails your builds. ## The paths that skip it 1. The job hits its wall-clock limit and the agent kills the client. A kill signal does not run a `finally` block. 2. The host reboots, the run environment is stopped, or the kernel's out-of-memory killer picks your client. 3. The connection to the driver or to a remote end drops before the delete command lands, orphaning the session on the far side. 4. The driver executable itself crashes, leaving the browser it started with no parent to shut it down. None of those are fixable by writing better teardown code, and that is the honest framing: `quit()` covers the expected paths, and a long-lived shared host needs an answer for the rest. ## The layers, and what each costs | layer | what it removes | what it costs | |---|---|---| | `quit()` on every session | everything, cleanly | nothing - this is the baseline, not an option | | scoped pre-run sweep of stale processes and temp directories | residue from earlier runs | can match work that is still live on a shared host | | a disposable run environment per run | all residue, unconditionally | provisioning time and infrastructure to own | | remote sessions instead of local browsers | residue leaves the runner entirely | the remote end now carries abandoned sessions until its own timeout | | monitoring process counts, live sessions and temp size | nothing - it only tells you | someone has to own the signal and act on it | ## How I would decide 1. **Baseline first.** Make `quit()` unconditional before buying anything above it. Every layer in that table is an expensive workaround for a cheap bug if the suite still forgets to quit. 2. **Choose by blast radius.** On a runner rebuilt for each job, disposal already solves it and a sweep is redundant. On a machine several jobs share, a broad process killer is genuinely dangerous - the residue of one job and the live browser of another look identical from the outside. 3. **Prefer disposal to cleanup where you can afford it.** Throwing the environment away is the only option that needs no rules about which processes are dead, which is why it survives the arrival of a second browser, a second suite and a new team. 4. **Consider pushing browsers off the runner.** With remote sessions the client owns no browser and no driver executable, so an unbounded local leak becomes a bounded remote one: an abandoned session holds its slot until the remote end's own session timeout reaps it. That timeout is a Grid configuration decision owned elsewhere; what you own is the choice to depend on it. 5. **Instrument whatever you add.** A backstop with no counter tells you nothing about whether the underlying bug is still there. ## Making a backstop honest - Scope it. Match on process ancestry, on a dedicated account, or on an age threshold longer than your longest run - never on the browser's name alone. - Run it **before** a run rather than after, so it can never race the run it is protecting. - Publish what it reaps per run. Zero is healthy; a steady non-zero count is a list of tests whose sessions never received Delete Session. - Name it for what it is. A script called "cleanup" acquires a reputation as infrastructure; one that reports three leaked sessions reaped stays visibly a symptom. ## What goes wrong when the backstop becomes the mechanism - Missing `quit()` calls stop being visible, so the number of them grows and the suite quietly loses the ability to run anywhere without the sweeper. - The killer's pattern eventually matches something live - a browser another job is using, or a developer's own window on a shared box. - Killing a driver skips its own cleanup, so the temporary profile directory it would have deleted survives; you convert a process leak into a slower disk leak. - Capacity planning drifts. The fleet gets sized for the leak instead of the workload, and the extra headroom hides the next leak too.