Unrecognized LSP requests are silently dropped instead of returning MethodNotFound (-32601)

[kylesnowschwartz]

The process_message case statement in lib/ruby_lsp/server.rb has no else clause, so when the server receives a request for an unsupported method (e.g. textDocument/prepareCallHierarchy), it matches no branch, returns nil, and never sends a response. The LSP spec requires servers to respond to any request bearing an id — for unsupported methods, that's error code -32601 (MethodNotFound). The silent drop causes well-behaved clients to hang indefinitely waiting for a response. Adding an else branch that calls send_message(Error.new(id: message[:id], code: -32601, message: "Method not found: #{message[:method]}")) when message[:id] is present would fix it.

[vinistock]

Thank you for the report. I agree that it would make sense to return MethodNotFound for any requests that the server doesn't implement, but I don't see that mentioned in the spec. You can infer that from the name of the error, but I didn't find text instructing servers to do so. Where did you find it?

Also, are you building an LSP client from scratch? I ask because the LSP doesn't support call hierarchy and we don't include that in our capabilities, so I wouldn't expect a client to send requests for a capability we don't support.

[kylesnowschwartz]

Sorry for the slow reply!

On the spec reference:

The requirement comes from JSON-RPC 2.0, which LSP builds on. Section 5 says:

"When a rpc call is made, the Server MUST reply with a Response, except for in the case of Notifications."

And Section 5.1 defines error code -32601 as "The method does not exist / is not available."

The LSP 3.17 spec reinforces this in a few places. The Request Message section says "Every processed request must send a response back to the sender of the request." The Response Message section says the receiver "still needs to return a response message to conform to the JSON-RPC specification." And ErrorCodes explicitly includes MethodNotFound: -32601, annotated // Defined by JSON-RPC.

You're right that the spec only names MethodNotFound explicitly for $/-prefixed requests. For standard methods it relies on capability negotiation to prevent the situation. But the underlying JSON-RPC contract (MUST reply to every Request) still applies.

On the client question:

Yes — this came up while building LSP support in Claude Code (Anthropic's CLI agent). It's not a traditional editor, so the capability-checking layer isn't as mature as VS Code's. The server correctly doesn't advertise call hierarchy support; the client shouldn't have sent the request. That's a client bug we have no control over because Anthropic doesn't prioritize these kinds of fixes.

But the silent drop is still a server-side issue: any request with an id that gets no response leaves the client hanging with no way to recover gracefully. Returning -32601 is cheap insurance against misbehaving clients and makes debugging much easier on both sides.

[vinistock]

Thank you for the details. We should definitely fix this, I tagged it as good first issue.

[IgorFroehner]

Hello guys! I created this PR fixing this like @kylesnowschwartz suggested: #4040