astral-sh/ruff · error

JSON parsing failure: {json_err}

Error message

JSON parsing failure:
{json_err}

What it means

`cast_request` extracts and deserializes a request's params into the typed parameters of handler `Req`. If the JSON fails to parse/validate against the expected type (`ExtractError::JsonError`), it is wrapped as `JSON parsing failure:` with the serde detail; a method mismatch is treated as an internal unreachable bug.

Source

Thrown at crates/ruff_server/src/server/api.rs:308

/// Tries to cast a serialized request from the server into
/// a parameter type for a specific request handler.
/// It is *highly* recommended to not override this function in your
/// implementation.
fn cast_request<Req>(
    request: server::Request,
) -> Result<(
    RequestId,
    <<Req as RequestHandler>::RequestType as Request>::Params,
)>
where
    Req: RequestHandler,
    <<Req as RequestHandler>::RequestType as Request>::Params: UnwindSafe,
{
    request
        .extract(Req::METHOD.as_str())
        .map_err(|err| match err {
            json_err @ server::ExtractError::JsonError { .. } => {
                anyhow::anyhow!("JSON parsing failure:\n{json_err}")
            }
            server::ExtractError::MethodMismatch(_) => {
                unreachable!(
                    "A method mismatch should not be possible here \
                    unless you've used a different handler (`Req`) than the one \
                    whose method name was matched against earlier."
                )
            }
        })
        .with_failure_code(server::ErrorCode::InternalError)
}

/// Sends back a response to the server, but only if the request wasn't cancelled.
fn respond<Req>(
    id: &RequestId,
    result: Result<<<Req as RequestHandler>::RequestType as Request>::Result>,
    client: &Client,
) where

View on GitHub (pinned to 26f38c119c)

Solutions

1. Log the raw request params in the client and validate them against the LSP schema for the method
2. Fix the client's serialization of params (correct types, required fields, DocumentUri formatting)
3. Update client and server to matching versions to eliminate schema skew
4. Test the request with an LSP inspector (e.g. vscode-lspInspector) to compare against a working client

Example fix

// before
{ "method": "textDocument/formatting", "params": { "uri": "file.py", "options": {} } }
// after
{ "method": "textDocument/formatting",
  "params": { "textDocument": { "uri": "file:///abs/file.py" }, "options": { "tabSize": 4, "insertSpaces": true } } }

// Client-side param validation before sendRequest
function validFormatParams(p: any): boolean {
  return p && typeof p.textDocument?.uri === 'string'
    && p.textDocument.uri.startsWith('file://')
    && typeof p.options?.tabSize === 'number'
    && typeof p.options?.insertSpaces === 'boolean';
}

// TypeScript
try {
  return await client.sendRequest('textDocument/formatting', params);
} catch (e) {
  if (/JSON parsing failure/.test(String(e.message))) {
    console.error('Malformed params sent to Ruff:', params); // fix sender
    return null;
  }
  throw e;
}

When it happens

Trigger: A client sends a request whose `params` do not match the LSP schema for that method — wrong field types, missing required fields, nulls where objects are expected — and the server dispatches it to the matched handler.

Common situations: Hand-rolled or buggy LSP clients sending malformed JSON-RPC; custom tooling constructing requests manually; client/server version skew where params schema changed; string-vs-number positions or URIs sent as plain strings instead of DocumentUri.

Related errors

• Attempted to add edits for a document that was already edite
• failed to deserialize diagnostic data: {err}
• Invalid command `{name}`
• MethodNotFound
• InternalError

AI-assisted analysis of astral-sh/ruff@26f38c119c (2026-09-05). Data as JSON: /api/errors/bfae109e0dbeca60. Report an issue: GitHub.