In a parallel Selenium suite, a case's first command lands on the previous case's session — what does that prove about the ThreadLocal driver holder?

## The one fact that makes this possible A thread-local entry belongs to the **thread**, not to the case. Test runners typically hand cases to a **pool of reused worker threads** rather than creating a thread per case, so the thread that ran *submit a new application to the tracker* is still alive, still pooled, and still carrying whatever its map held when that case finished. When the pool hands it *archive a rejected application*, the entry from the first case is right where it was left. That is the only way one case's command can land on another case's session without any driver ever being shared between two threads. The two cases ran **sequentially, on one thread**. Nothing raced; something simply was not cleared. This is also why the failure is so hard to place. It appears in the second case, but the defect is in the first case's teardown, and the two may sit in different classes written by different people. ## Two symptoms, one cause Which symptom you get depends entirely on whether the previous case's teardown quit the driver before it failed to remove the entry. | Previous teardown did | What the next `get()` returns | The first command then | How it reads in the report | |---|---|---|---| | `quit()`, no `remove()` | a driver whose session id is already cleared | throws `NoSuchSessionException` | looks like a remote-end or environment fault | | neither `quit()` nor `remove()` | a live driver on the previous browser | succeeds, on the wrong page | looks like a product bug or a stale assertion | The second row is the dangerous one. The tracker is showing the previous case's filtered board and the previous candidate's applications, so an assertion about *this* case's newly created application fails with a message about a missing row. Nothing in that message points at the holder. ## Confirming the holder is at fault The confirmation is cheap and does not need a debugger: 1. **Log the thread name beside the session id** at every `set()`, `get()` and `stop()`. `RemoteWebDriver.getSessionId()` gives you the identifier the remote end knows the session by. 2. **Assert in setup that the holder is empty** before it sets anything. A non-null value at the top of a case is proof, on its own, that the previous case on that thread leaked its entry. 3. **Correlate by thread, not by time.** Line up the failing case with the case that ran immediately before it *on the same thread name*, not the one before it in the report. 4. **Count `set()` calls against `remove()` calls** for the whole run. Any difference is a leaked entry, and the count tells you how many. 5. **Reproduce by shrinking the pool.** Fewer worker threads than cases forces reuse, so the failure stops being intermittent. If the log shows two different case names writing and reading the *same* session id on the *same* thread name, the diagnosis is finished. ## The teardown paths that actually skip remove() In practice the clear is missed in a small number of recurring ways: - An exception thrown in setup **after** `set()` but before the case body, where the runner then decides teardown does not apply. - A teardown that returns early when it sees a null local variable and never reaches the holder at all. - `quit()` and `remove()` written as two statements in sequence, with `quit()` throwing on an unreachable browser. - A failure listener that quits the driver to release the browser and never touches the holder that still points at it. - Teardown running on a **different thread** from setup, so `remove()` clears an entry on the wrong map and leaves the real one behind. - A per-class teardown paired with a per-method `set()`, so the clear runs once for many entries. ## Why this is not the shared-driver bug, and why ThreadGuard stays silent It is tempting to file this as two threads sharing one driver, and the fix is different, so the distinction matters. A genuinely shared driver fails everywhere and immediately: commands from two threads interleave on one session, and `ThreadGuard.protect(WebDriver)` raises a `WebDriverException` naming the constructing thread and the calling thread. A leaked entry produces none of that. The previous case created the driver **on the very thread that is now reusing it**, so `ThreadGuard` compares two identical thread ids and says nothing. A holder-based suite that has passed a `ThreadGuard` audit can still be leaking entries on every case, which is precisely why the audit you need here is the empty-holder assertion in setup rather than a thread-identity wrapper. ## Closing it The repair is the ordering and the ownership, not extra vigilance. Put `quit()` in a `try` and `remove()` in the matching `finally`, so a driver that cannot be quit still clears its entry. Route every case through one shared teardown rather than per-class copies. Make `get()` throw a message that names the current thread when the holder is empty, so a missing setup fails at the first helper instead of returning null into page code. Then keep the started-versus-stopped counter as a standing check, because the failure it catches is invisible until the day the pool gets smaller than the suite.