A client sends a request declaring a protocol version that the server does not implement and receives an UnsupportedProtocolVersion error. What should the client do next?
Select an answer to reveal the explanation.
Short Explanation
The server's telling you which languages it speaks — it put the list right in the error. You pick one you both know and ask again. Don't wait it out, and don't strip the version field; that just earns a different error.
Full Explanation
When a server does not implement the protocol version a request declares, whether the version is unknown or one the server chooses not to support, it MUST respond with UnsupportedProtocolVersionError, code -32022. The error's data lists the versions the server supports and echoes the requested one. The client SHOULD select a mutually supported version from that list and retry the request, or surface an error to the user if no compatible version exists. This keeps negotiation per request, with no handshake. Sending initialize to renegotiate a session-wide version reverts to legacy behaviour; a modern-only server has no initialize method, and this revision has no protocol sessions. Retrying the same version after a delay treats a deterministic incompatibility as a transient fault; the server will reject it again. Removing the version field makes the request malformed, because protocolVersion is a required _meta field, and the server must reject it with -32602 and, on HTTP, a 400 status. Exam caveat: a client can avoid the round trip by calling server/discover first and choosing from supportedVersions, but it is not required to. Operational check: send a request with an unsupported version, confirm the -32022 error lists supported versions, and verify the client's retry uses one of them and succeeds.