LSP executeCommand and 'Method not found' alert - who's requesting who?!

I wanted to follow up on this issue as I think the Deno LSP must’ve been changed to not require external commands to be registered with the LSP client.

I’ve been working on adding LSP support for Java using JDTLS and ran into a very similar issue with executing code actions. The error message is “-32601 No delegateCommandHandler for java.apply.workspaceEdit”.

This error message is sent from the LSP server (JDTLS) to the Nova LSP client in response to a “workspace/executeCommand” request from the Nova LSP client. Here is an example back-and-forth conversation between the Nova LSP client and the JDTLS server:

JDTLS --- Received JSON-RPC response: number(1) textDocument/codeAction
{
  "id" : 1,
  "result" : [
    {
      "title" : "Add Javadoc comment",
      "command" : "java.apply.workspaceEdit",
      "arguments" : [
        {
          "documentChanges" : [
            {
              "textDocument" : {
                "uri" : "file:\/\/\/Users\/branden.vennes\/code\/oss\/OpenLineage\/client\/java\/generator\/src\/main\/java\/io\/openlineage\/client\/Generator.java",
                "version" : null
              },
              "edits" : [
                {
                  "newText" : "\/**\n *\n *\/\n",
                  "range" : {
                    "end" : {
                      "character" : 2,
                      "line" : 39
                    },
                    "start" : {
                      "character" : 2,
                      "line" : 39
                    }
                  }
                }
              ]
            }
          ],
          "changes" : {
          }
        }
      ]
    }
  ]
}
JDTLS --- Sending JSON-RPC request: number(11) workspace/executeCommand
{
  "id" : 11,
  "params" : {
    "arguments" : [
      {
        "changes" : {

        },
        "documentChanges" : [
          {
            "textDocument" : {
              "version" : null,
              "uri" : "file:\/\/\/Users\/branden.vennes\/code\/oss\/OpenLineage\/client\/java\/generator\/src\/main\/java\/io\/openlineage\/client\/Generator.java"
            },
            "edits" : [
              {
                "newText" : "\/**\n *\n *\/\n",
                "range" : {
                  "start" : {
                    "character" : 2,
                    "line" : 39
                  },
                  "end" : {
                    "character" : 2,
                    "line" : 39
                  }
                }
              }
            ]
          }
        ]
      }
    ],
    "command" : "java.apply.workspaceEdit"
  },
  "method" : "workspace\/executeCommand",
  "jsonrpc" : "2.0"
}
JDTLS --- Received JSON-RPC response: number(11) workspace/executeCommand
{
  "jsonrpc" : "2.0",
  "id" : 11,
  "error" : {
    "message" : "No delegateCommandHandler for java.apply.workspaceEdit",
    "code" : -32601
  }
}

I looked into why JDTLS would respond with this error and discovered that other LSP clients (VS Code and Neovim) have support for defining custom command handlers which the LSP server can execute directly. See nvim-jdtls/lua/jdtls.lua at ad5ab1c9246caa9e2c69a7c13d2be9901b5c02aa · mfussenegger/nvim-jdtls · GitHub and vscode-java/src/extension.ts at 9b0f0aca80cbefabad4c034fb5dd365d029f6170 · redhat-developer/vscode-java · GitHub.

In the case of VS Code, these commands are standard command-palette commands you’d register in your extension. For Neovim there is a vim.lsp.commands variable which can be used to register custom LSP commands: Lsp - Neovim docs.

Nova could have similar functionality where registering a command in Nova java.apply.workspaceEdit also allows the command to be used by the LSP server. In the case of the original issue here, the deno.cache command could be registered with Nova as a standard Command and be used by the Deno LSP server.