astral-sh/ruff · warning · Error

MethodNotFound

MethodNotFound

Error message

Unknown request: {method}

What it means

The request router in api.rs matched the incoming method against no registered handler, so the server replies with LSP error code MethodNotFound and logs 'Received request {method} which does not have a handler'. This is a protocol-level 'feature not implemented' response, not a crash.

Source

Thrown at crates/ty_server/src/server/api.rs:154

        ),
        requests::CallHierarchyIncomingCallsRequestHandler::METHOD => {
            background_request_task::<requests::CallHierarchyIncomingCallsRequestHandler>(
                req,
                BackgroundSchedule::Worker,
            )
        }
        requests::CallHierarchyOutgoingCallsRequestHandler::METHOD => {
            background_request_task::<requests::CallHierarchyOutgoingCallsRequestHandler>(
                req,
                BackgroundSchedule::Worker,
            )
        }
        lsp_types::ShutdownRequest::METHOD => sync_request_task::<requests::ShutdownHandler>(req),

        method => {
            tracing::warn!("Received request {method} which does not have a handler");
            let result: Result<()> = Err(Error::new(
                anyhow!("Unknown request: {method}"),
                server::ErrorCode::MethodNotFound,
            ));
            return Task::immediate(id, result);
        }
    }
    .unwrap_or_else(|err| {
        tracing::error!("Encountered error when routing request with ID {id}: {err}");

        Task::sync(move |session, client| {
            if matches!(err.code, ErrorCode::InternalError) {
                client.show_error_message(format!(
                    "ty failed to handle a request from the editor. {}",
                    session.client_name().log_guidance()
                ));
            }

            respond_silent_error(
                id,

View on GitHub (pinned to 672bb4edf0)

Solutions

  1. Gate each request on the capabilities returned in the initialize result before sending
  2. Verify the exact method string against the LSP spec / ty's supported methods
  3. Update the client extension and ty server to matching versions
  4. Treat the MethodNotFound response as informational and disable that feature in the client

Example fix

// before
await connection.sendRequest('textDocument/codeLens', params);  // server: MethodNotFound

// after
if (initResult.capabilities.codeLensProvider) {
  await connection.sendRequest('textDocument/codeLens', params);
}
Defensive patterns

Strategy: validation

Validate before calling

// TS: gate every non-core request on advertised capabilities
const caps = initResult.capabilities;
const sendIfSupported = (method: string, capability: unknown, params: unknown) =>
  capability ? client.sendRequest(method, params) : Promise.resolve(null);

await sendIfSupported('textDocument/codeLens', caps.codeLensProvider, params);

Type guard

const isSupportedMethod = (method: string): boolean =>
  supportedMethodsFromCapabilities(initResult.capabilities).includes(method);

Try / catch

// If sent anyway, handle the MethodNotFound response explicitly
try { await client.sendRequest(method, params); }
catch (e: any) {
  if (e?.code === -32601) { disableFeature(method); return; }
  throw e;
}

Prevention

When it happens

Trigger: The client sends a request method ty's server does not implement — e.g. codeLens, semanticTokens/full, or inlayHints when no handler exists — typically because the client ignores the server's advertised capabilities.

Common situations: Editor extensions enabling features the server never advertised, version skew between client plugin and ty server, custom/typo'd method strings, or clients assuming ruff-server and ty-server share handlers.

Related errors


AI-assisted analysis of astral-sh/ruff@672bb4edf0 (2026-08-16). Data as JSON: /api/errors/ed11b5958f4754e5. Report an issue: GitHub.