In Selenium Grid, what is a Node's stereotype and which session requests will match that slot?

## What a slot is, and what a stereotype is A Selenium 4 Grid **Node** is the process that owns real browsers on one machine. It does not offer "browsers" in the abstract; it offers a fixed list of **slots**, built once when the Node starts, and each slot is a seat that holds exactly one WebDriver session at a time. Every slot carries a **stereotype**: an immutable set of capabilities describing what a session started in that seat will be. The Node publishes its stereotypes when it registers with the Distributor, and from then on the Grid routes purely on that published description. The pharmacy prescription queue's suite needs Chrome 131 and Firefox 133 on Linux. That is two stereotypes, and the machine hosting them has to declare both. Nothing about having the browsers installed makes them routable on its own. ## Where a stereotype is written Stereotypes live in a TOML config file under repeated `[[node.driver-configuration]]` tables, or on the command line with `--driver-configuration`. The TOML form is the readable one and is the form Selenium's own documentation recommends. Four keys are recognised inside a block: - **`display-name`** — mandatory. The human label the Node prints and reports for those slots. - **`stereotype`** — mandatory. A JSON string of capabilities, such as `{"browserName": "chrome", "browserVersion": "131"}`. - **`max-sessions`** — optional. How many identical slots this one block builds; falls back to the Node's own `--max-sessions`. - **`webdriver-executable`** — optional. The driver binary to launch, recorded on the stereotype as `se:webDriverExecutable`. Leave out either mandatory key and the Node refuses to start, throwing a `ConfigException` that names the offending block. The same settings can be typed inline: ``` node --detect-drivers false --driver-configuration display-name="Prescription queue" max-sessions=4 stereotype='{"browserName":"chrome","browserVersion":"131"}' ``` ## What the Node adds before it registers The stereotype the Grid sees is not always byte-for-byte the one you typed. `NodeOptions.enhanceStereotype` fills gaps first: 1. If `platformName` is absent, the Node stamps the platform the process is actually running on. Omitting it is a convenience, not a wildcard. 2. If the Node is configured to expose a VNC stream, it adds `se:vncEnabled` and `se:noVncPort`. 3. If managed downloads are enabled and the browser supports them, it adds `se:downloadsEnabled`. That matters while debugging: read the stereotype the Node logged at startup, not the one still open in your editor. ## How a request is matched against a stereotype `DefaultSlotMatcher` is the class that decides, and its rules are narrower than most people assume. | What the session request sends | How the matcher treats it | |---|---| | `browserName` | must equal the stereotype's; absent or empty matches any slot | | `browserVersion` | compared as a version; absent, empty or `stable` matches any slot | | `platformName` | must equal the stereotype's, or be a platform the declared value covers | | `goog:`, `moz:`, `ms:`, `safari:`, `se:` keys | never matched — handed to the driver instead | | a custom prefixed key the stereotype also declares | must be equal, compared without case sensitivity | | `se:downloadsEnabled` set to true | matches only a stereotype that also declares it true | | an empty capability set | matches nothing at all | Two consequences follow, and they are the whole point. First, **vendor options do not route**. Putting `goog:chromeOptions` with a beta binary path in a stereotype changes which browser starts, but it never influences which slot the Grid picks. Second, a value no stereotype declared cannot be matched. There is no negotiation and no downgrade. ## The prescription-queue Node, end to end 1. The Node reads its TOML file at startup and parses each `[[node.driver-configuration]]` block. 2. For each block it finds the driver that supports the stereotype and builds `max-sessions` identical session factories — one slot each. 3. It enhances every stereotype, logs what it registered, and publishes the set to the Distributor. 4. A request for Chrome 131 is compared against the slots and reserves the first free one that matches. 5. A request for Chrome 130 matches nothing here, because nothing on this Node says `130`. ## What a stereotype is not The stereotype decides only *whether* a slot can serve a request. What happens to a request while every matching slot is busy belongs to the session queue, and the capability object the client assembles belongs to the client library. The Node's declaration answers one question: here is what I have, and here is how many of it.