A Selenium Grid Node runs Chrome, yet requests pinning browserVersion never match its slot. Why, and what fixes it?

## The symptom The prescription-queue suite pins `browserVersion` so that a dispensing screen is always exercised on the browser build the pharmacy actually deploys. The Node has Chrome installed, was started with driver detection on, registered cleanly, and is heartbeating. Requests that name only `browserName` land on it happily. Requests that also pin `browserVersion` never do. Nothing in the Node's own health tells you why. ## What an auto-detected slot actually advertises Detection is deliberately thin. `ChromeDriverInfo.getCanonicalCapabilities()` returns exactly one capability, `browserName: chrome`; `GeckoDriverInfo` returns exactly `browserName: firefox`. The Node then runs `NodeOptions.enhanceStereotype`, which stamps `platformName` from the running host and adds `se:` keys for VNC or managed downloads when those are on. **The installed browser's version is never read into the stereotype.** Selenium 4 does not launch the browser to interrogate it at configuration time, so an auto-detected slot advertises a browser name and a platform and nothing else. ## How browserVersion is actually compared `DefaultSlotMatcher` delegates to `SemanticVersionComparator`, which splits both strings on dots and walks the parts. Two asymmetries decide everything: - A part missing from the **request** inherits the stereotype's part at that position. - A part missing from the **stereotype** defaults to `0`. - An empty stereotype version sorts last and never compares equal. | Stereotype declares | Request asks for | Match? | |---|---|---| | `131.0.6778.85` | nothing at all | yes — the request states no preference | | `131.0.6778.85` | `stable` | yes — the literal string is treated as a wildcard | | `131.0.6778.85` | `131` | yes — the request's missing parts inherit the stereotype's | | `131` | `131.0.6778.85` | no — the stereotype's missing parts become `0`, so `0` faces `6778` | | nothing (auto-detected) | `131` | no — an empty declared version never compares equal | The last row is the bug. The fourth row is the one that bites teams who tried to fix it by declaring a bare major version. ## Why the Node still looks healthy Registration proves only that the Node reached the Distributor and is sending heartbeats. Routing is a separate, per-request decision taken against the stereotype the Node published. A perfectly healthy Node whose stereotype nobody asks for simply sits idle, so the fault is invisible from the Node's own liveness and shows up only as requests that never find a home. It is also why the failure survives the usual first reactions. Restarting the Node changes nothing, because it rebuilds exactly the same detected slot from the same configuration. Adding a second machine changes nothing, because the second one detects Chrome the same way. Only changing the declaration moves the outcome. ## The fix 1. Read the stereotype the Node logged when it registered, and compare it with the capabilities the failing request sends. Trust the log, not the config file. 2. Replace detection with an explicit `[[node.driver-configuration]]` block carrying `browserVersion` in the stereotype JSON. 3. Set `detect-drivers = false` in the `[node]` section, so the unversioned detected slot does not linger beside your declared one and quietly absorb unpinned traffic. 4. Declare the **fully qualified** version, not the major alone. A four-part declaration serves both a request for `131` and a request for `131.0.6778.85`; a bare `131` serves only the first. 5. Pin the matching driver binary with `webdriver-executable` in the same block, so the slot's promise and the process it launches cannot drift apart. 6. Restart the Node. Slots are built once from the configuration the process started with; editing the file changes nothing until then. ## The traps next door - **Vendor prefixes never route.** `goog:`, `moz:`, `ms:`, `safari:` and `se:` keys are skipped by the matcher. A stereotype that pins a beta binary through `goog:chromeOptions` still matches plain Chrome requests. - **Custom prefixed keys must be everywhere.** A key like `pharmacy:tier` is checked only against stereotypes that declare it; a Node silent on the key skips the check and matches anyway. Selenium's documentation is explicit that a custom capability has to be set on every Node and sent on every request. - **`platformName` is stamped, not blank.** Leaving it out of your config does not make the slot platform-agnostic; the Node fills in its own platform. - **Managed downloads are matched.** A request setting `se:downloadsEnabled` to true only matches a stereotype that also declares it true. - **An empty capability set matches nothing**, so a request that sends no capabilities at all is not a wildcard.