jdt.ls 1.23.0 issues invalid reverse request "workspace/executeClientCommand'

[puremourning]

Since updating to 1.23.0, I'm seeing the following invalid message being sent to ycmd:

2023-05-01 19:15:40,029 - DEBUG - RX: Received message: b'{"jsonrpc":"2.0","id":"3","method":"workspace/executeClientCommand","params":{"command":"_java.reloadBundles.command","arguments":[]}}'
2023-05-01 19:15:40,029 - DEBUG - TX: Sending response: b'Content-Length: 79\r\n\r\n{"error":{"code":-32601,"message":"Method not found"},"id":"3","jsonrpc":"2.0"}'

The workspace/executeClientCommand method does not exist in the LSP: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

this is leading to an exception trace.

[jdneo]

Maybe we need to add a client capability here. Definition of workspace/executeClientCommand is here: https://github.com/redhat-developer/vscode-java/blob/bd03b35664fd9c72a4de06f1d85ad14302ccca12/src/protocol.ts#L147

We use it to trigger a command execution from server to client.

[rgrunber]

Yup. The server requests a command be executed on the client side without any check as to whether the client supports this :

eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/JDTLanguageServer.java

Lines 429 to 435 in f4d1a4a

	/**
	* Ask client to check if any bundles need to be synchronized.
	*/
	private void synchronizeBundles() {
	try {
	Object commandResult = JavaLanguageServerPlugin.getInstance()
	.getClientConnection().executeClientCommand("_java.reloadBundles.command");

A "command" is just supposed to represent some logic/task that the client can carry out simply by referring to it through an identifier. I would think this isn't harmful as the client should just fail to carry out the unknown request, but maybe certain clients can't gracefully recover so we should handle definitely handle it. I think it would have to be an extendedClientCapability though.

There are other locations where we call executeClientCommand without checking the capability though they aren't as easily exposed as they require some extra work to implement.

eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CompletionHandler.java

Lines 213 to 214 in f4d1a4a

	JavaLanguageServerPlugin.getInstance().getClientConnection()
	.executeClientCommand(onSelectedCommand);

relies on the delegate command java.completion.onDidSelect which is not something many clients are as likely to be calling.

eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/OrganizeImportsHandler.java

Line 122 in f4d1a4a

Object commandResult = JavaLanguageServerPlugin.getInstance().getClientConnection().executeClientCommand(CLIENT_COMMAND_ID_CHOOSEIMPORTS, documentUri, selections, restoreExistingImports);

relies on the client calling java/organizeImports . There are other ways of triggering organize imports thoug so this is also less likely to happen.

[hopehadfield]

I'm interested in working on this