Chapter 03Lesson 04~165 minutes

WebDriver Architecture, W3C Protocol, Sessions, and Capabilities: Diagnostics, Failure Modes, and Production Practices

Diagnose WebDriver failures at the protocol layer before changing locators, adding sleeps, restarting Grid, or copying legacy Selenium 2/3 advice that no longer describes the current contract.

Invalid argumentSession not createdUnknown commandInvalid sessionLegacy traps

Learning objectives

  • Distinguish capability validation errors from capability matching and session-creation failures.
  • Explain invalid-session and unknown-command errors as protocol/lifecycle evidence.
  • Diagnose unavailable browser/platform requests without retries that hide the cause.
  • Reject legacy JSON Wire Protocol and DesiredCapabilities-only guidance when it conflicts with Selenium 4 APIs.
  • Identify unprefixed vendor-specific capabilities as invalid at the W3C endpoint boundary.
  • Apply the course evidence-first diagnostic sequence to a Grid-backed failure.

1. Diagnostic sequence for protocol incidents

Preserve evidence before changing state

The following diagram visualizes the relationships described in Diagnostic sequence for protocol incidents. Read the nodes in sequence and use the arrows to connect the conceptual state changes to the explanation around the diagram.

flowchart TD
  F["First failure"] --> V["Selenium / browser / driver / Grid versions"]
  V --> Q["Requested capabilities"]
  Q --> N["Was a session ID returned?"]
  N --> C["Returned capabilities / context"]
  C --> P["Command + route + arguments"]
  P --> G["Grid / remote-end logs"]
  G --> X["Smallest correction"]
  X --> R["Controlled rerun"]

The first branch is crucial: if no session ID was returned, element locators and DOM timing did not cause the failure. Stay at request validation, matching, browser/driver startup, Grid capacity, or environment restrictions until the session exists.

2. Error taxonomy

The following table organizes the key choices and evidence for Error taxonomy. Use it together with the surrounding prose so the rows serve as a comparison aid rather than standalone rules.

Failure Meaning Typical evidence Wrong shortcut
invalid argument request/capability value or key is invalid HTTP 400 + JSON error retrying same payload
session not created new session could not be established request + remote-end/Grid error debugging locators
unsupported capability / no matching slot environment cannot satisfy request requested vs available stereotypes loosening unrelated assertions
unknown command remote end does not know requested command route HTTP 404 protocol error adding waits
invalid session id session does not exist or is no longer active old session ID + teardown timeline reusing stale driver object

3. Intentionally invalid unprefixed extension capability

The WebDriver standard reserves unrecognized implementation-specific capabilities for namespaced keys containing a colon. This raw request is intentionally invalid because academyMode is neither a standard capability nor a namespaced extension:

{
  "capabilities": {
    "alwaysMatch": {
      "browserName": "chrome",
      "academyMode": true
    },
    "firstMatch": [{}]
  }
}

An endpoint node should reject it as an invalid argument rather than inventing semantics. If you need browser-vendor configuration, use the browser Options class and its proper namespace. Do not “fix” an error by renaming a key to a random prefix; the vendor must actually define the capability.

4. Unavailable capability is different from malformed capability

A syntactically valid request can still be impossible to match—for example, requesting a platform/browser combination your Grid does not offer. In the Chapter 03 checkpoint, Grid runs with --reject-unsupported-caps true, which lets the Distributor reject unsupported capabilities immediately. Without that setting, the request may enter the New Session Queue and wait for capacity until its timeout policy is reached.

Preserve the requested browserName/platformName and the Grid status/node stereotype evidence. The correction is to request an available environment or provision the required capacity, not to increase Selenium command timeouts.

5. Invalid session ID is lifecycle evidence

After driver.quit(), the remote end deletes the active session. Reusing the same driver object is a programming error because its session identity is dead. In a Grid-backed run, the Grid server remains alive, so the protocol can return an explicit invalid-session error for a later command.

from selenium import webdriver
from selenium.common.exceptions import InvalidSessionIdException

options = webdriver.ChromeOptions()
driver = webdriver.Remote("http://127.0.0.1:4444", options=options)
old_id = driver.session_id
driver.quit()

try:
    print(driver.title)
except InvalidSessionIdException:
    print(f"session {old_id} is no longer active")

Do not create a new hidden session inside an error handler merely to make the next line pass. Lifecycle ownership should be explicit at the test/fixture boundary.

6. Unknown command versus unsupported high-level feature

unknown command means the remote end does not recognize a requested protocol route. That is different from an element not found, an assertion failure, or a capability mismatch. Possible causes include stale client/server combinations, manually crafted endpoints, proxy routing mistakes, or unsupported extension commands.

When ordinary Selenium methods produce an unknown-command error, capture Selenium binding, Grid/server, driver, and browser versions before upgrading or downgrading anything. If you are using browser-specific or BiDi/CDP features, verify that the exact binding/browser/version supports the API.

7. Legacy JSON Wire Protocol and DesiredCapabilities traps

Selenium 4 follows W3C WebDriver. Older examples may show Selenium 2/3 JSON Wire routes, /wd/hub as if mandatory everywhere, Grid 3 hub/node syntax, or direct DesiredCapabilities-only constructors. Historical material can explain evolution, but it should not define a new Selenium 4 lesson.

Current Python webdriver.Remote requires an options object. Current Selenium documentation instructs users to use browser Options classes for capabilities. If an old snippet conflicts with the pinned binding API, verify the current API rather than forcing compatibility through deprecated patterns.

8. Security and evidence handling

Protocol logs can expose URLs, file paths, proxy settings, browser debugger addresses, cloud-vendor metadata, or test data. Capture only what you need and sanitize it before sharing. Never expose Grid publicly for the sake of “seeing the HTTP traffic.” Use loopback/private endpoints and local logs.

Do not disable TLS verification, browser sandboxing, or enterprise controls to bypass a session-creation error. Those settings change the security boundary and may hide the real incompatibility.

Knowledge check

What distinguishes invalid argument from session not created?

Why does --reject-unsupported-caps true help the checkpoint?

What should you debug first if no session ID was ever returned?

Why is an unprefixed academyMode capability invalid?

What does invalid session ID usually tell you?

Why avoid legacy JSON Wire examples in new Selenium 4 content?

Next lesson

Prove local and remote equivalence—and a negotiation failure

The checkpoint creates two equivalent sessions, compares evidence, then requests a capability the local Grid cannot satisfy and documents the exact failure boundary.

Official references and version notes

Version and compatibility note

Version-sensitive behavior was rechecked against current Selenium and W3C primary documentation on 2026-08-27. The mandatory path pins Selenium Python 4.47.0, uses Python 3.10+, one installed supported Chromium-family browser, Java 11+ for the local Selenium Server/Grid Standalone exercise, Selenium Server 4.47.0, and loopback-only endpoints at 127.0.0.1. The Grid lab starts Standalone with --selenium-manager true and --reject-unsupported-caps true so driver discovery can remain automatic and an intentionally unavailable capability is rejected deterministically. WebDriver BiDi is explained only as a distinct bidirectional protocol boundary here; Chapter 18 teaches its evolving APIs in depth.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.