Error with codeAction/resolve

[jsadusk]

First I wanted to say, lspx works great for diagnostic and formatting. I've used it with basedpyright and ruff successfully, through emacs/eglot. It is also the only lsp multiplexer I've found that supports workspace configuration.

But I noticed if you try to use a codeAction, like ruff's organizeImports, lspx crashes. Here's the stacktrace:

Error: Unhandled method codeAction/resolve
      at handleResponse (file:///tmp/deno-compile-lspx/.deno_compile_node_modules/localhost/vscode-jsonrpc/8.2.1/lib/common/connection.js:565:48)
     at handleMessage (file:///tmp/deno-compile-lspx/.deno_compile_node_modules/localhost/vscode-jsonrpc/8.2.1/lib/common/connection.js:345:13)
     at processMessageQueue (file:///tmp/deno-compile-lspx/.deno_compile_node_modules/localhost/vscode-jsonrpc/8.2.1/lib/common/connection.js:362:17)
     at file:///tmp/deno-compile-lspx/.deno_compile_node_modules/localhost/vscode-jsonrpc/8.2.1/lib/common/connection.js:334:13
     at ext:deno_web/02_timers.js:35:14
     at eventLoopTick (ext:core/01_core.js:213:13) {
   code: -32601,
   data: undefined
 }

The jsonrpc request that preceeded it was:

{"jsonrpc":"2.0","id":82,"method":"codeAction/resolve","params":{"data":"file:///home/<path_redacted>","kind":"source.organizeImports.ruff","title":"Ruff: Organize imports"}}

Before this happened, there was a successful textDocument/codeAction request which got all the available code actions for both servers.

[jsadusk]

Also of note, the method codeAction/resolve is in method2capability:
https://github.com/thefrontside/lspx/blob/main/lib/capabilities.ts#L57
So why doesn't the jsonrpc connection see this as an available method? I'd fix this but I don't work in typescript/js enough to understand where the methods are being registered.

GitHub

lspx/lib/capabilities.ts at main · thefrontside/lspx

language server multiplexer, supervisor, and interactive shell - thefrontside/lspx

[cowboyd]

I believe this is happening because the codeAction/resolve needs to only be sent to the server that originally listed the code action. When returning the list of code actions, we need to somehow "wrap" the server that it came from in response data, and then, when the code action is resolved, unwrap the server, and then only dispatch the code action to that server.

[cowboyd]

@jsadusk Are you able to create a transcript of the JSONRPC that is failing?

[dgutov]

When returning the list of code actions, we need to somehow "wrap" the server that it came from in response data, and then, when the code action is resolved, unwrap the server, and then only dispatch the code action to that server.

Looking at the spec, a CodeAction value can have a data field with implementation-defined contents.

There is also a dataSupport field in codeActionClientCapabilities.

And:

/**
* Whether code action supports the data property which is
* preserved between a textDocument/codeAction and a
* codeAction/resolve request.
*
* @SInCE 3.16.0
*/
dataSupport?: boolean;

lspx could wrap data sent by the server with its own object, or just add an attribute anyway.

[dhanak]

Any updates on this issue?

[cowboyd]

I haven't made a progress lately, mostly because I've been using deno which bundles a bunch of language servers already. I'd probably pick this up the next time I'm on a node project.

[cowboyd]

But that said, I am very happy to pair to develop a PR for this with anybody that is interested in working on it.