A Selenium seat-map suite now fails every session with ChromeDriver's 'only supports Chrome version' error - how do you stop it recurring?
answer
- Nothing in the suite changed overnight
- It fails before any page loads
- One half moved, one half froze
- Only the major version decides
- Pin a non-updating build and its driver
basics
~20 sChromeDriver refuses any session whose Chrome major version differs from its own. Pin both halves to one version - a Chrome for Testing build that does not auto-update plus the driver published for it - and upgrade them together.
solid answer
~40 sChrome updated itself past the pinned `chromedriver`, and ChromeDriver refuses a session whose Chrome **major** version is not its own — in Selenium 4 that arrives as `SessionNotCreatedException` at `new ChromeDriver(...)`, before the seat map is ever loaded. The message names both numbers and the browser binary path it launched, which is the whole diagnosis. The durable fix is to pin both halves: a **Chrome for Testing** build, which does not auto-update, plus the `chromedriver` published for that same version, wired in with `ChromeOptions.setBinary(...)` and `ChromeDriverService.Builder().usingDriverExecutable(...)`. Keep the version string in one place so a bump moves both halves in a single commit, and log `Capabilities.getBrowserVersion()` on the first session so every run records the pair that produced it.
code
java · 29 linesimport java.io.File;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeDriverService;
import org.openqa.selenium.chrome.ChromeOptions;
public class SeatMapSession {
private static final String PIN = "141.0.7390.54";
public static void main(String[] args) {
ChromeDriverService service = new ChromeDriverService.Builder()
.usingDriverExecutable(new File("/opt/cft/" + PIN + "/chromedriver"))
.build();
ChromeOptions options = new ChromeOptions();
options.setBinary(new File("/opt/cft/" + PIN + "/chrome"));
ChromeDriver driver = new ChromeDriver(service, options);
try {
String actual = driver.getCapabilities().getBrowserVersion();
if (!actual.startsWith(PIN.substring(0, PIN.indexOf('.')))) {
throw new IllegalStateException("seat map pinned to " + PIN + ", found " + actual);
}
driver.get("https://example.com/flights/FL482/seat-map");
} finally {
driver.quit();
}
}
}go deeper
Be ready to recognise the message and say what it means: the driver and the browser are on different major versions. Knowing that it happens at session creation, before any page loads, is most of the answer.
Explain the mechanism: ChromeDriver is built for one Chrome major, checks the browser it launched, and refuses the new-session command otherwise. Name the two settings that pin browser and driver separately.
Show the production judgment. Diagnose from the message rather than the diff, pin both halves to one recorded version, upgrade them in a single change, and make every run log the pair that produced it.
Own the tradeoff between reproducibility and currency: a pinned pair guarantees repeatable runs but drifts away from the browser real passengers use, so somebody has to own when the pin moves and who reviews it.
## What the message actually says `ChromeDriver` drives exactly one **major version** of Chrome. When the browser it starts reports a different major, it refuses the **new session** command outright, and the Selenium 4 Java client surfaces that refusal as `SessionNotCreatedException` thrown from the line that constructs the driver. The text has a fixed shape: ``` session not created: This version of ChromeDriver only supports Chrome version 141 Current browser version is 142.0.7444.60 with binary path /usr/bin/google-chrome ``` Three facts are in there, and together they are the whole diagnosis: the major the **driver** supports, the full version the **browser** reported, and the **binary path** that was actually launched. Read the path as carefully as the numbers — it is common for the Chrome you meant to drive and the Chrome that actually started to be two different installs on the same machine. ## Why the seat-map suite broke with no commit - Chrome **auto-updates** itself in the background; a `chromedriver` copied onto the machine or checked into the repository does not. - The pin only ever covered one half, so the browser kept moving while the driver stood still. - Only a **major** bump breaks the pair. Minor and build differences are tolerated, which is why the seat-map suite survived weeks of updates and then died in a single morning. - The failure lands at `new ChromeDriver(...)`, before the seat map is ever requested, so every case fails identically and the report reads like an outage rather than a test defect. - Nothing changed in version control, so the first instinct — bisect the suite — burns an hour on the wrong axis. ## Local and CI show the same drift differently | | Engineer's machine | Pipeline agent | |---|---|---| | Where the browser comes from | one everyday Chrome install that updates itself whenever it restarts | whatever browser the run environment supplies that day | | Who notices first | one person, on the morning their Chrome relaunched | everyone at once, on the first run after the environment moved | | Typical report | "green in the pipeline, red on my laptop, and I changed nothing" | "green yesterday, red today, no commits in between" | | Half that is stale | the driver, frozen the day somebody downloaded it | the driver, frozen when it was placed in that environment | The asymmetry is useful when you triage. A refusal on **one** machine points at that machine's browser having moved; a refusal everywhere at once points at whatever supplies the browser to every run. Either way the cure is the same, and it is not a cure until both halves are pinned. ## Pinning both halves 1. Choose a **Chrome for Testing** build — a Chrome distribution published for automation that does not update itself — and record its full version, for example `141.0.7390.54`. 2. Take the `chromedriver` published for that same version. Chrome for Testing offers a matching driver for every browser build it publishes, so the pair always exists. 3. Point Selenium at both explicitly rather than hoping the machine agrees: the browser through `ChromeOptions.setBinary(...)`, the driver through `ChromeDriverService.Builder().usingDriverExecutable(...)` or the `webdriver.chrome.driver` system property. 4. Keep the version string in **one** place the suite reads, so a bump is a single edit that moves both halves together and a reviewer can see it as one number. ## Keeping the pin honest - Log `Capabilities.getBrowserVersion()` and the driver path from the first successful session. A run that cannot say which pair produced it is not reproducible, however green it was. - Upgrade the pair deliberately, in one change. A commit that moves one half alone is the original defect being reintroduced. - Prefer a legible failure to a mysterious one: compare the majors yourself at start-up and fail with "seat-map suite pinned to 141, found 142". - Treat a green run as evidence for a **version pair**, not for "Chrome" in the abstract. ## What does not fix it - Retrying the session. The refusal is deterministic, so a retry only multiplies the wait before the identical message returns. - Downloading whatever driver is newest, by hand, when it breaks. That restores today's run and re-arms exactly the same trap for next month. - Rewriting the seat-map locators. Nothing reached the page, so no locator was ever evaluated. - Lengthening waits. The exception is thrown while the session is being created, before any timeout could apply to anything.
- The pinned pair looks right, yet one engineer's machine still fails at session creation. What do you check?The binary path printed in the message, which names the Chrome that actually started. A stale `webdriver.chrome.driver` value in that shell, a second driver earlier on `PATH`, or a `setBinary` path that no longer exists will all launch something other than the pinned pair while the code looks correct.
- Why does grabbing the newest available driver sometimes fix nothing?Because the newest driver supports the newest Chrome major. If the machine's Chrome is older, the mismatch simply inverts and you get the same refusal with the numbers swapped. The driver must match the browser that is actually on the machine, not the latest one published.
- How do you make this failure legible in the run report instead of a raw stack trace?Read `Capabilities.getBrowserVersion()` from the first session and log it with the driver path, then compare majors against the pinned version yourself and fail with a message naming both. The reader sees 'pinned to 141, found 142' instead of decoding a session-not-created dump.
saying these in an interview costs you the question
- Calls it flakiness and wraps driver construction in a retry
- Blames the seat-map locators although no page was ever loaded
- Says only the driver needs pinning and the browser can float
- Downloads a newer driver by hand each time it breaks
- Thinks a minor or build version difference refuses the session