Internal error (code -32603) on "textDocument/semanticTokens/full" request

[vargonis]

Hi there. I'm getting the error in the title and I assume the problem is on my side. My java -version is

openjdk version "19.0.2" 2023-01-17
OpenJDK Runtime Environment (build 19.0.2+7-Ubuntu-0ubuntu322.04)
OpenJDK 64-Bit Server VM (build 19.0.2+7-Ubuntu-0ubuntu322.04, mixed mode, sharing)

and I'm launching the server like this:

java -Declipse.application=org.eclipse.jdt.ls.core.id1 \
  -Dosgi.bundles.defaultStartLevel=4 \
  -Declipse.product=org.eclipse.jdt.ls.core.product \
  -Dlog.level=ALL \
  -Xmx1G \
  --add-modules=ALL-SYSTEM \
  --add-opens=java.base/java.util=ALL-UNNAMED \
  --add-opens=java.base/java.lang=ALL-UNNAMED \
  -jar language_servers/res/java/plugins/org.eclipse.equinox.launcher_1.6.400.v20210924-0641.jar \
  -configuration language_servers/res/java/config_linux \
  -data tmp

After initializing with

{"jsonrpc": "2.0", "method": "initialize", "params": {"rootUri": "file:///home/vargonis/Ennova/coding-assistant/GestionePratiche"}, "id": 0}

I send

{"jsonrpc": "2.0", "method": "textDocument/semanticTokens/full", "params": {"textDocument": {"uri": "sources/api/gestionepratiche-data/src/main/java/it/er/pcore/gestionepratiche/data/DictionaryProcedureDomainRepository.java"}}, "id": 1}

and get the following:

{"jsonrpc":"2.0","id":1,"error":{"code":-32603,"message":"Internal error.","data":"java.util.concurrent.CompletionException: java.lang.NullPointerException: Cannot invoke \"java.lang.Integer.intValue()\" because the return value of \"java.util.Map.get(Object)\" is null\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:1311)\n\tat java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1841)\n\tat java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1806)\n\tat java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)\nCaused by: java.lang.NullPointerException: Cannot invoke \"java.lang.Integer.intValue()\" because the return value of \"java.util.Map.get(Object)\" is null\n\tat org.eclipse.jdt.ls.core.internal.handlers.BaseDocumentLifeCycleHandler$DocumentMonitor.\u003cinit\u003e(BaseDocumentLifeCycleHandler.java:765)\n\tat org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$52(JDTLanguageServer.java:1130)\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"}}

Help, please! I'm not a Java programmer, I'm just trying to use the language server in a ML project. Thanks in advance.

[0dinD]

Hi! You're running into #1993. The last time I had a look at it, I noted:

But it is a bit strange that the document version is null when a DocumentMonitor is constructed for a semantic tokens request. That would either suggest a client error (such as not sending textDocument/didOpen before the semantic tokens request), or something more obscure.

Because I thought that clients were supposed to always send textDocument/didOpen before sending any other document-related requests (this seems to be how VSCode does it). But I don't know where I got that from, because now that I read the LSP specification again, I can't find any such requirement. In fact, the specification says that "a server’s ability to fulfill requests is independent of whether a text document is open or closed". Therefore, in the case where a client (such as yours) sends textDocument/semanticTokens/full without sending textDocument/didOpen, I believe the server should still send the tokens back without any error, so #1993 is actually not a client error at all.

I'll send a PR to fix #1993, but until that has been released, the easiest workaround for you is to just send a textDocument/didOpen notification before the textDocument/semanticTokens/full request (and then ideally a textDocument/didClose notification when you're done with the file).

[vargonis]

Hi OdinD, thanks for your help! I have not had time yet to try your suggestion, but I'm sure you nailed it. Regarding the specification, I indeed was not sending the textDocument/didOpen message precisely because of the paragraph you cited, so yes I think it would be good to fix the issue. Thanks again!