#17638·selenium

[ Feature]: Remove deprecated JSON Wire ErrorCodes / Response.status (java)

Author: titusfortnerCreated Jun 5, 2026Updated Sep 15, 2026
LabelsC-javaI-enhancementA-needs-triaging

Description

ErrorCodes and Response.status/getStatus()/setStatus() are leftover JSON Wire Protocol plumbing. They're still load-bearing in the W3C path: ErrorHandler resolves exceptions via getExceptionType(int) keyed off the integer Response.getStatus(). Removal is two independent efforts.

Interim state landed separately: both are now plain @Deprecated with javadoc pointing at the replacement (no forRemoval, to avoid promising a removal that isn't scheduled and to keep the build warning-free until the migration below happens).

Track A — Response.status integer (internal only)

No external consumer found; doable entirely within this repo.

  • Re-point ErrorHandler (lines 102-104, 258) off getExceptionType(int) onto the W3C state string via ErrorCodec.decode().
  • Migrate remaining internal readers of getStatus()/setStatus(): Response.fromJson, AbstractHttpResponseCodec, W3CHttpResponseCodec, W3CHandshakeResponse, ProtocolHandshake, ResponseConverter.
  • Flip Response.status/getStatus()/setStatus() to @Deprecated(forRemoval = true) once the internal callers above are gone (no consumers left to warn).
  • Remove Response.status/getStatus()/setStatus().

Track B — ErrorCodes (public API, Appium depends on it)

Appium subclasses it (ErrorCodesMobile extends ErrorCodes) and injects via new ErrorHandler(new ErrorCodesMobile(), true). Requires cross-repo sequencing:

  1. (Selenium) Make ErrorCodec extensible — public API to register custom state → exception mappings (currently private ctor + private static ERRORS list).
  2. (Selenium) Add an ErrorHandler constructor taking ErrorCodec; old ErrorHandler(ErrorCodes, …) delegates and stays deprecated.
  3. (Appium) Replace the subclass with one registration: "No such context found" → NoSuchContextException. (then wait for an Appium release)
  4. (Selenium) Mark ErrorCodes + ErrorHandler(ErrorCodes, …) forRemoval, then remove in a major release.

Have you considered any alternatives or workarounds?

Keep ErrorCodes indefinitely as legacy API and never remove it — needs no Appium coordination, reclaims no code.

Does this apply to specific language bindings?

Java