Calling vim.ui.select's `on_choice` after `codeAction/resolve` results in "-32603: Internal error."

ibhagwan commented 5 months ago

LSP client configuration

Should be reproduced with any working nvim-jdtls setup, my specific setup can be found at: https://github.com/ibhagwan/nvim-lua/blob/main/after/ftplugin/java.lua

Eclipse.jdt.ls version

v1.30.1 (installed via mason.nvim)

Steps to Reproduce

Context: https://github.com/ibhagwan/fzf-lua/issues/1007

Steps to reproduce:

Install fzf-lua
Run code actions, look for an action that requires further codeAction/resolve for the diff, for example an "Inline local variable" action (window is relative, cursor is under the letter s):

As you can see from the screnshot the workspace edit action was resolved correctly generating the diff seen in the preview:
Select the action with enter and receive "-32603: Internal error."

Runing code actions without the previewer works as expected (as no codeAction/resolve call is made):

:FzfLua lsp_code_actions previewer=false

Tried with both sync (client.request_sync ) and async call (client.request), calling code can be found at: https://github.com/ibhagwan/fzf-lua/blob/36195a230246fc44e8144ee0b454fc022ac5326b/lua/fzf-lua/previewer/codeaction.lua#L163-L178

Expected Result

Expected to complete the workspace edit.

Actual Result

Action edit fails with "-32603: Internal error.":

mfussenegger commented 5 months ago

Can you show the server logs?

The inline actions work fine with the stock code action handling in neovim:

https://github.com/neovim/neovim/blob/11e8e14628413e45e46d2d2a7af53d0da0c9dcdd/runtime/lua/vim/lsp/buf.lua#L683-L700

The only difference I see is that fzf-lua doesn't check dynamic capabilities, and that it always fails if there is an error. Although that should be fine for the jdtls case, but in neovim it was changed slightly due to the haskell language server, see https://github.com/neovim/neovim/commit/4a09c178a19097c295521892c889f1f196fff100

But I think that particular action also requires client command support, handled by: https://github.com/neovim/neovim/blob/11e8e14628413e45e46d2d2a7af53d0da0c9dcdd/runtime/lua/vim/lsp.lua#L1357-L1388

niveK77pur commented 5 months ago

Can confirm that actions seem to work fine with neovim's stock action handling, as I demonstrated in my initial issue: https://github.com/ibhagwan/fzf-lua/issues/1007. However, the stock actions also do not have any preview.

Here are my lsp logs when I run the inline code action as an example (via fzf-lua).

[START][2024-01-20 15:06:04] LSP logging initiated
[ERROR][2024-01-20 15:06:04] .../vim/lsp/rpc.lua:734    "rpc"   "/home/kevinb/.local/share/nvim/mason/bin/jdtls"    "stderr"    "WARNING: Using incubator modules: jdk.incubator.vector\n"
[ERROR][2024-01-20 15:06:05] .../vim/lsp/rpc.lua:734    "rpc"   "/home/kevinb/.local/share/nvim/mason/bin/jdtls"    "stderr"    "Jan 20, 2024 3:06:05 PM org.apache.aries.spifly.BaseActivator log\nINFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic\n"
[ERROR][2024-01-20 15:06:05] .../vim/lsp/rpc.lua:734    "rpc"   "/home/kevinb/.local/share/nvim/mason/bin/jdtls"    "stderr"    "Jan 20, 2024 3:06:05 PM org.apache.aries.spifly.BaseActivator log\nINFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic\n"
[WARN][2024-01-20 15:06:10] ...lsp/handlers.lua:137 "The language server jdtls triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[ERROR][2024-01-20 15:08:35] .../vim/lsp/rpc.lua:734    "rpc"   "/home/kevinb/.local/share/nvim/mason/bin/jdtls"    "stderr"    "Jan 20, 2024 3:08:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError\nSEVERE: Internal error: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \njava.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \n\tat java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)\n\tat java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)\n\tat java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)\n\tat java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)\n\tat java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387)\n\tat java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312)\n\tat java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843)\n\tat java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808)\n\tat java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188)\nCaused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \n\tat org.eclipse.core.runtime.Assert.isTrue(Assert.java:119)\n\tat org.eclipse.core.runtime.Assert.isTrue(Assert.java:104)\n\tat org.eclipse.text.edits.TextEdit.<init>(TextEdit.java:153)\n\tat org.eclipse.text.edits.MultiTextEdit.<init>(MultiTextEdit.java:65)\n\tat org.eclipse.text.edits.CopySourceEdit.performSourceComputation(CopySourceEdit.java:266)\n\tat org.eclipse.text.edits.CopySourceEdit.traverseSourceComputation(CopySourceEdit.java:260)\n\tat org.eclipse.text.edits.TextEditProcessor.computeSources(TextEditProcessor.java:210)\n\tat org.eclipse.text.edits.TextEditProcessor.executeDo(TextEditProcessor.java:195)\n\tat org.eclipse.text.edits.TextEdit.dispatchPerformEdits(TextEdit.java:742)\n\tat org.eclipse.text.edits.TextEditProcessor.performEdits(TextEditProcessor.java:158)\n\tat org.eclipse.text.edits.TextEdit.apply(TextEdit.java:714)\n\tat org.eclipse.jdt.ls.core.internal.TextEditConverter.visit(TextEditConverter.java:154)\n\tat org.eclipse.text.edits.MultiTextEdit.accept0(MultiTextEdit.java:146)\n\tat org.eclipse.text.edits.TextEdit.accept(TextEdit.java:641)\n\tat org.eclipse.jdt.ls.core.internal.TextEditConverter.convert(TextEditConverter.java:76)\n\tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertTextEdit(ChangeUtil.java:287)\n\tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertTextChange(ChangeUtil.java:278)\n\tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertSingleChange(ChangeUtil.java:120)\n\tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertToWorkspaceEdit(ChangeUtil.java:109)\n\tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertToWorkspaceEdit(ChangeUtil.java:91)\n\tat org.eclipse.jdt.ls.core.internal.handlers.CodeActionResolveHandler.resolve(CodeActionResolveHandler.java:49)\n\tat org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$15(JDTLanguageServer.java:793)\n\tat org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)\n\tat java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)\n\t... 6 more\n\n"

EDIT: I forgot to mention that I DO NOT use nvim-jdtls! I simply got the jdtls language server via mason and everything set up with lsp-zero. So the question begs if the issue is maybe not within the jdtls language server itself.

ibhagwan commented 5 months ago

The inline actions work fine with the stock code action handling in neovim:

@mfussenegger, perhaps I wasn’t clear enough in the description, in-line actions also works fine with fzf-lua as long as the previewer is turned off.

When the previewer is used, certain actions require additional resolving, therefore while vim.ui.select is awaiting confirmation, an additional call is performed, codeAction/resolve (in order to display the diff in preview) that seems to trigger the bug which then makes on_choice fail.

The only difference I see is that fzf-lua doesn't check dynamic capabilities, and that it always fails if there is an error.

I explored the runtime code and fzf-lua’s on_choice code does what it should, evidently the exact code action works if the previewer is turned off.

But I think that particular action also requires client command support, handled by:

I don’t believe this is relevant to this issue as this part is handled by the runtime after I handover the action with the on_choice callback.

Can you show the server logs?

I’ll look for the logs and post them below.

ibhagwan commented 5 months ago

My server logs seem to match these of @niveK77pur:

edited NLs for clarity

[START][2024-01-20 07:56:45] LSP logging initiated
[ERROR][2024-01-20 07:56:45] .../vim/lsp/rpc.lua:734    "rpc"   "java"  "stderr"    "WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign\n"
[ERROR][2024-01-20 07:56:46] .../vim/lsp/rpc.lua:734    "rpc"   "java"  "stderr"    "Jan 20, 2024 7:56:46 AM org.apache.aries.spifly.BaseActivator log\nINFO: Registered provider ch.qos.logback.classic.servlet.LogbackServletContainerInitializer of service jakarta.servlet.ServletContainerInitializer in bundle ch.qos.logback.classic\n"
[ERROR][2024-01-20 07:56:46] .../vim/lsp/rpc.lua:734    "rpc"   "java"  "stderr"    "Jan 20, 2024 7:56:46 AM org.apache.aries.spifly.BaseActivator log\nINFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic\n"
[WARN][2024-01-20 07:56:51] ...lsp/handlers.lua:137 "The language server jdtls triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[ERROR][2024-01-20 07:56:51] ...lsp/handlers.lua:535    "Jan 20, 2024, 7:56:51 AM Command _java.reloadBundles.command not supported on client"
[ERROR][2024-01-20 07:57:06] .../vim/lsp/rpc.lua:734    "rpc"   "java"  "stderr"    "Jan 20, 2024 7:57:06 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint fallbackResponseError\n
SEVERE: Internal error: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \n
java.util.concurrent.CompletionException: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \n\
tat java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)\n\
tat java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)\n\
tat java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:649)\n\
tat java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)\n\
tat java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)\n\
tat java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)\n\
tat java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)\n\
tat java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)\n\
tat java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)\n
Caused by: org.eclipse.core.runtime.AssertionFailedException: assertion failed: \n\
tat org.eclipse.core.runtime.Assert.isTrue(Assert.java:119)\n\
tat org.eclipse.core.runtime.Assert.isTrue(Assert.java:104)\n\
tat org.eclipse.text.edits.TextEdit.<init>(TextEdit.java:153)\n\
tat org.eclipse.text.edits.MultiTextEdit.<init>(MultiTextEdit.java:65)\n\
tat org.eclipse.text.edits.CopySourceEdit.performSourceComputation(CopySourceEdit.java:266)\n\
tat org.eclipse.text.edits.CopySourceEdit.traverseSourceComputation(CopySourceEdit.java:260)\n\
tat org.eclipse.text.edits.TextEditProcessor.computeSources(TextEditProcessor.java:210)\n\
tat org.eclipse.text.edits.TextEditProcessor.executeDo(TextEditProcessor.java:195)\n\
tat org.eclipse.text.edits.TextEdit.dispatchPerformEdits(TextEdit.java:742)\n\
tat org.eclipse.text.edits.TextEditProcessor.performEdits(TextEditProcessor.java:158)\n\
tat org.eclipse.text.edits.TextEdit.apply(TextEdit.java:714)\n\
tat org.eclipse.jdt.ls.core.internal.TextEditConverter.visit(TextEditConverter.java:154)\n\
tat org.eclipse.text.edits.MultiTextEdit.accept0(MultiTextEdit.java:146)\n\
tat org.eclipse.text.edits.TextEdit.accept(TextEdit.java:641)\n\
tat org.eclipse.jdt.ls.core.internal.TextEditConverter.convert(TextEditConverter.java:76)\n\
tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertTextEdit(ChangeUtil.java:287)\n\
tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertTextChange(ChangeUtil.java:278)\n\
tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertSingleChange(ChangeUtil.java:120)\n\
tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertToWorkspaceEdit(ChangeUtil.java:109)\n\
tat org.eclipse.jdt.ls.core.internal.ChangeUtil.convertToWorkspaceEdit(ChangeUtil.java:91)\n\
tat org.eclipse.jdt.ls.core.internal.handlers.CodeActionResolveHandler.resolve(CodeActionResolveHandler.java:49)\n\
tat org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$15(JDTLanguageServer.java:793)\n\
tat org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)\n\
tat java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)\n\
t... 6 more\n\n"

deathbeam commented 5 months ago

So I accidentally found "solution" for this I think which is basically this: https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/jdtls.lua#L117

And it looks like its because of https://github.com/eclipse/eclipse.jdt.ls/issues/376 (e.g JDTLS being scuffed, yay)

EDIT:

Nvm, the issue persists with change modifiers to final code action still.

  package com.example.project;

  public class Calculator {

    public int add(int a, int b) {
      return a + b;
    }

  }

Easy way to reproduce on this

ibhagwan commented 5 months ago

Ty for the find @deathbeam! I guess we can close this issue as this has nothing to do with nvim-jdtls.

mfussenegger / nvim-jdtls