Eglot fails when starting sorbet typechecker LSP server due to a :requestMethod keyword in the response

[offbyone]

It seems that the sorbet language server sends back some unexpected response keys; strictly, from what I can glean, the LSP spec is silent on how to handle extra keys, so it'd be super keen if eglot could handle them.

The issue was raised w/ Sorbet here: sorbet/sorbet#6125

The debug backtrace is here:

Debugger entered--Lisp error: (error "Keyword argument :requestMethod not one of (:metho...")
  error("Keyword argument %s not one of (:method :id :error..." :requestMethod)
  jsonrpc-connection-receive(#<eglot-lsp-server eglot-lsp-server-56f7f038> (:jsonrpc "2.0" :id 1 :requestMethod "initialize" :result (:capabilities (:textDocumentSync 1 :hoverProvider t :completionProvider (:triggerCharacters ["." ":" "@" "#"]) :definitionProvider t :typeDefinitionProvider t :implementationProvider t :referencesProvider t :documentHighlightProvider :json-false :documentSymbolProvider :json-false :workspaceSymbolProvider t :codeActionProvider (:codeActionKinds ["quickfix" "source.fixAll.sorbet" "refactor.extract" "refactor.rewrite"] :resolveProvider t) :documentFormattingProvider :json-false :renameProvider (:prepareProvider t) :sorbetShowSymbolProvider t)) :jsonrpc-json "{\"jsonrpc\":\"2.0\",\"id\":1,\"requestMethod\":\"initialize\",\"result\":{\"capabilities\":{\"textDocumentSync\":1,\"hoverProvider\":true,\"completionProvider\":{\"triggerCharacters\":[\".\",\":\",\"@\",\"#\"]},\"definitionProvide..."))
  #f(compiled-function (conn msg) #<bytecode -0x18151225cab05815>)(#<eglot-lsp-server eglot-lsp-server-56f7f038> (:jsonrpc "2.0" :id 1 :requestMethod "initialize" :result (:capabilities (:textDocumentSync 1 :hoverProvider t :completionProvider (:triggerCharacters ["." ":" "@" "#"]) :definitionProvider t :typeDefinitionProvider t :implementationProvider t :referencesProvider t :documentHighlightProvider :json-false :documentSymbolProvider :json-false :workspaceSymbolProvider t :codeActionProvider (:codeActionKinds ["quickfix" "source.fixAll.sorbet" "refactor.extract" "refactor.rewrite"] :resolveProvider t) :documentFormattingProvider :json-false :renameProvider (:prepareProvider t) :sorbetShowSymbolProvider t)) :jsonrpc-json "{\"jsonrpc\":\"2.0\",\"id\":1,\"requestMethod\":\"initializ..."))
  apply(#f(compiled-function (conn msg) #<bytecode -0x18151225cab05815>) (#<eglot-lsp-server eglot-lsp-server-56f7f038> (:jsonrpc "2.0" :id 1 :requestMethod "initialize" :result (:capabilities (:textDocumentSync 1 :hoverProvider t :completionProvider (:triggerCharacters ["." ":" "@" "#"]) :definitionProvider t :typeDefinitionProvider t :implementationProvider t :referencesProvider t :documentHighlightProvider :json-false :documentSymbolProvider :json-false :workspaceSymbolProvider t :codeActionProvider (:codeActionKinds ["quickfix" "source.fixAll.sorbet" "refactor.extract" "refactor.rewrite"] :resolveProvider t) :documentFormattingProvider :json-false :renameProvider (:prepareProvider t) :sorbetShowSymbolProvider t)) :jsonrpc-json "{\"jsonrpc\":\"2.0\",\"id\":1,\"requestMethod\":\"initializ...")))
  timer-event-handler([t 26210 1476 784438 nil #f(compiled-function (conn msg) #<bytecode -0x18151225cab05815>) (#<eglot-lsp-server eglot-lsp-server-56f7f038> (:jsonrpc "2.0" :id 1 :requestMethod "initialize" :result (:capabilities (:textDocumentSync 1 :hoverProvider t :completionProvider (:triggerCharacters ["." ":" "@" "#"]) :definitionProvider t :typeDefinitionProvider t :implementationProvider t :referencesProvider t :documentHighlightProvider :json-false :documentSymbolProvider :json-false :workspaceSymbolProvider t :codeActionProvider (:codeActionKinds ["quickfix" "source.fixAll.sorbet" "refactor.extract" "refactor.rewrite"] :resolveProvider t) :documentFormattingProvider :json-false :renameProvider (:prepareProvider t) :sorbetShowSymbolProvider t)) :jsonrpc-json "{\"jsonrpc\":\"2.0\",\"id\":1,\"requestMethod\":\"initializ...")) nil 0 nil])

[joaotavora]

The server sin't using an LSP extension with extra keys. Eglot can handle those. The server is using a JSONRPC extension with extra keys, it's quite different: it has nothing to do with LSP. You can raise a jsonrpc.el bug, but my recommendation is to fix this is the server.

[joaotavora]

As I've tried to explain. It's not Eglot ignoring them, it's jsonrpc.el. Eglot is for LSP, these are not LSP keys, they are extraneous JSONRPC keys. There could even be other jsonrpc.el applications besides Eglot relying on this behaviour. I'm not the jsonrpc.el maintainer anymore.

But also, if Sorbet is an LSP/JSONRPC application, what prevents it from sending this key inside the LSP application parts?

BTW, Eglot is known to work with close to one hundred servers and each has its quirks. But this is the first time in 7 years I've encountered this one.

[offbyone]

Is there any powerful reason not to modify the cl-destructuring-bind in jsonrpc.el to use &allow-other-keys in the binding?

(defun jsonrpc-connection-receive (conn foreign-message)
  "Process FOREIGN-MESSAGE just received from CONN.
This function will destructure MESSAGE and call the appropriate
dispatcher in CONN."
  (cl-destructuring-bind (&rest whole &key method id error params result _jsonrpc &allow-other-keys)
      (jsonrpc-convert-from-endpoint conn foreign-message)

?

[joaotavora]

Are you reading what I write?

There could even be other jsonrpc.el applications besides Eglot relying on this behaviour.

[joaotavora]

Also, in case you missed those parts as well, here they again are as clear as I could write them.

• You are asking in the wrong forum. This is Eglot's discussion forum. The change you want is in jsonrpc.el
• Eglot is not the only JSONRPC client.
• I am not jsonrpc.el 's maintainer anymore, so you may report a bug to [email protected] to get support on this issue.
• My recommendation would be to solve this in the server, as it seems to be something only useful for a test client (reading in the linked issue).
• A possibility for solving it server-side is to store the extra inside the params

In case you are indeed still reading, have you noticed that jsonrpc-convert-from-endpoint? It's one of the last things I've added to jsonrpc.el when I was maintaining it. It's specifically designed to support JSONRPCesque protocols. You may add a method to that generic function (you can research this), that removes the offending key. That' s what the DAP Emacs/jsonrpc.el applications do, for example (dap.el and zapp.el). Here's an example https://github.com/joaotavora/zapp/blob/a1a640a1496877ca0d91d3aad8c5e76f49cfff10/zapp.el#L214

So this would be my second recommendation.

[offbyone]

Thanks for the pointers. Less so for the tone. I'm not an expert in this language or ecosystem, so I was asking in the hopes of learning more. I won't bother you further, because frankly I'm not interested in being insulted in the process of learning.

[joaotavora]

I don't know what you make of _your_ tone, but from my perspective it was jarring to see your retorts completely ignore what I wrote in good faith and insist on the same point as if I had written nothing.

…

On Tue, Jun 11, 2024 at 10:10 PM Chris Rose ***@***.***> wrote: Thanks for the pointers. Less so for the tone. I'm not an expert in this language or ecosystem, so I was asking in the hopes of learning more. I won't bother you further, because frankly I'm not interested in being insulted in the process of learning. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

-- João Távora