In Codespaces, workspace symbols sometimes are empty.

[Eskibear]

Above screenshot is taken when I starts a new Codespaces session with spring-petclinic repo. Notice that dashboard and workspace symbols are both empty.

When app is not running, dashboard shows beans/endoint mappings based on results from workspace/symbols requests. If it's empty, dashboard shows nothing.
When app is running, some users are complaining about they cannot switch between "show defined beans" and "show all beans", it always shows all beans. Root cause is also the same, a bean is recognized as "defined in workspace" iff it's also a workspace symbol. (it's reported that after restarting codespaces, it has chance to get back to normal)

[Eskibear]

https://github.com/microsoft/vscode-spring-boot-dashboard/actions/runs/4448736100/jobs/7811943881 might be related.

1 failing

1. Extension Test Suite
   Can view static beans and mappings:
   Error: Timeout of 300000ms exceeded.

Dashboard polls for workspace symbols until the result is not empty. The failure is proabably because of the same issue.

[martinlippert]

Looks like this problem occurs (more or less) randomly, right? Hard to say what is going wrong here, but we should definitely get to the bottom of it.

My initial guess is that the initialization sequence between the Java tooling and the Spring tooling is the root cause of this. The classpath listener mechanism is relatively complex and might be a source for race conditions, but it would be good to verify this assumption somehow before diving deeper here.

[Eskibear]

Looks like this problem occurs (more or less) randomly, right?

Yes. It occurs randomly for Codespaces, seldom on my local machine, always on GitHub action's Windows agent (recently since Mar.17, see status of recent commits in dashboard's repo, no ideas so far).

The classpath listener mechanism is relatively complex and might be a source for race conditions.

Might be. My gut feeling is the less powerful the machine is, the more like the issue occurs.

[Eskibear]

It's probably due to [email protected], which is released on Mar.17. And from the logs I find last success was using [email protected].

Another proof is, in microsoft/vscode-spring-boot-dashboard#299 , when I forced to use [email protected] , it worked again.

//cc @testforstephen @jdneo @rgrunber @CsCherrYY for awareness.

[BoykoAlex]

I have a feeling this might be similar to the issue observed in Eclipse when Boot LS was started and shut down in quick sequence over a short period of time. The vscode version of starting/stopping Boot LS still looks at boot projects presence to start/stop boot ls while Eclipse version only looks at boot project presence to start Boot LS once and then never stop it.

I have added logging to JDT LS extension in our Boot code (see ebddbc6)... If this issue is observed again please paste the JDT LS log here. I suspect that Boot LS started/stopped a number of times and the last is likely to be the Boot LS stop. Let try to confirm this hypothesis.

[Eskibear]

I see below error in CI failure. jdtls-log.zip

!ENTRY org.springframework.tooling.jdt.ls.extension 4 0 2023-03-29 07:13:17.425
!MESSAGE org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request workspace/executeClientCommand failed with message: command 'sts4.classpath.nsJawcWt' not found
!STACK 0
java.util.concurrent.CompletionException: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request workspace/executeClientCommand failed with message: command 'sts4.classpath.nsJawcWt' not found
	at java.base/java.util.concurrent.CompletableFuture.reportJoin(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture.join(Unknown Source)
	at org.eclipse.jdt.ls.core.internal.JavaClientConnection.executeClientCommand(JavaClientConnection.java:93)
	at org.springframework.tooling.jdt.ls.extension.ClasspathListenerHandler$1.executeClientCommand(ClasspathListenerHandler.java:34)
	at org.springframework.tooling.jdt.ls.commons.classpath.SendClasspathNotificationsJob.bufferMessage(SendClasspathNotificationsJob.java:164)
	at org.springframework.tooling.jdt.ls.commons.classpath.SendClasspathNotificationsJob.run(SendClasspathNotificationsJob.java:146)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Request workspace/executeClientCommand failed with message: command 'sts4.classpath.nsJawcWt' not found
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:209)
	at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:193)
	at org.eclipse.jdt.ls.core.internal.ParentProcessWatcher.lambda$1(ParentProcessWatcher.java:144)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)
	at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)
	at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

[BoykoAlex]

@Eskibear looks to me that the Boot LS is started up fine and on time. Seems that the issue is classpath listener is added and then removed. I have added more logging to Boot LS JdtLsProjectCache and have added a possible fix to the issue. Therefore, I'd like to ask you try the Boot extension one more time. It should include d4f931e. If you see the issue again please attach Boot LS log and JDT Ls log :-)

The issue in my mind is the race condition. The initial value for enabling classpath listening is false for vscode while then once java mode switches from Hybrid to Standard classpath listening is enabled. I think by the time classpath listening is enabled due to java mode change the initial value of classpasth listening is not applied since it is waiting for the Boot LS initi cycle to complete. Therefore, init cycle completes and initial value is applied disabling the classpath listening. I have modified the command to enable/disable classpath listening to wait until Boot LS is initialized which should include initial enabled value to be applied before any of the enable/disable commands execute.

[Eskibear]

I re-run CI job in microsoft/vscode-spring-boot-dashboard#303 once and above error was still there (although this time it succeeded). This is because the latest pre-release version of vscode-spring-boot in vscode's marketplace is still 1.46.2023032804, which is installed when performing the tests...
I'll give it a try after a new version (including your commit) is out.

[martinlippert]

@Eskibear The new pre-release version is on the marketplace now.

[Eskibear]

No luck. Here is another failed run: https://github.com/microsoft/vscode-spring-boot-dashboard/actions/runs/4551207290?pr=303

Same error as above. See: jdtls-log.zip

[Eskibear]

please attach Boot LS log and JDT Ls log

Sorry, I forgot the Boot LS log. Let me update the config to also collect Boot LS log file.

[BoykoAlex]

@Eskibear yes, please - the Boot LS log is the most helpful at this point.

[Eskibear]

Here it is, hope it helps.

jdtls-log.zip
boot-ls-log.zip
From CI failure in https://github.com/microsoft/vscode-spring-boot-dashboard/actions/runs/4566546801

[BoykoAlex]

@Eskibear Thanks for posting the logs. I still see that enable classpath listener command is executed before initial value is applied. Therefore the hypothesis stays but the fix changes to: 97b1304.
Please give it another try :-)

[Eskibear]

Great, it works now! I tried several times, and all passed.

Attaching logs below, and you may want to check whether they are as expected.
boot-ls-log.zip
jdtls-log.zip
From https://github.com/microsoft/vscode-spring-boot-dashboard/actions/runs/4572485741/jobs/8071793254?pr=303

BTW from boot-ls.log I find dashboard is querying symbols too frequently, and some of them are unnecessary. I'm going to fix that in dashboard.

[BoykoAlex]

I glanced at the logs - they seem to look as I'd expect them to. I have reverted extra logging changes as I consider this issue to be fixed :-) @Eskibear thanks for helping fixing the issue!-)