Introduce capability to check if workspace has exited improperly.

[rgrunber]

• Fixes Exceptions activating vscode-java extension #2405
• .snap files under the workspace metadata location indicate in improper workspace shutdown

[testforstephen]

This fix is fine for me, but I have one concern. It would result in a fresh import and affect the project import speed. Before we determine to apply this fix, can we create another PR to monitor how often the .snap file appears in telemetry? I want to know how likely this situation is and how many users it affects. If it’s rare, we can clean the workspace automatically. If not, we might consider looking for a better solution. What do you think?

[rgrunber]

Sounds fine. I can just modify this PR to also call fireTraceEvent so its accessible through the API, and temporarily avoid doing the cleanup. That way everything stays mostly the same and java.cleanworkspace's reason key having a value of automatic will represent the occurrence through the telemetry API.

Update: I've re-used java.ls.error.notification from

vscode-java/src/standardLanguageClient.ts

Line 292 in 9ab7039

name: "java.ls.error.notification",

and just provided the message from when the workspace exits with unsaved changes.

[testforstephen]

LGTM

I found a problem.

[rgrunber]

I don't think we can conclude that the workspace existing with unsaved changes is always harmful. As an example :

I took a simple project (can be invisible or even a small Maven one)

1. Open the project folder in VS Code for the first time, or alternatively clear the language server workspace

On the first import, if you watch the workspace folder that corresponds to the project you should see :

watch -n1 -d 'find . -name "*.snap"'

./redhat.java/jdt_ws/.metadata/.plugins/org.eclipse.core.resources/0.snap
...
...

3. Now attempt to kill the language server at least 5 times (to ensure it stops trying to start up again). You'll know you've succeeded when you see the server status show a 👎 (thumbs down) icon.
4. Now that there's no server controlling the workspace, shut off the VS Code client.
5. The 0.snap file from above will not have disappeared.
6. Now start VS Code again on the same workspace.

You'll see

!ENTRY org.eclipse.core.resources 2 10035 2024-01-25 16:00:12.263
!MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes.

but as far as I can tell, the language server starts up and works as normal. So I don't think we can conclude that this error is always harmful :\ There could be a chance that something else happened prior to the workspace exiting with unsaved changes that resulted in an unrecoverable state.

[testforstephen]

but as far as I can tell, the language server starts up and works as normal. So I don't think we can conclude that this error is always harmful :\ There could be a chance that something else happened prior to the workspace exiting with unsaved changes that resulted in an unrecoverable state.

This aligns with my previous observation. Most of the time the unsaved changes can be restored well upon reopening vscode. One case that cannot be recovered is the error "Caused by: org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '/spring-petclinic/target/classes/templates/welcome.html' not found.", which requires a clean cache as the workaround.

[rgrunber]

Do you have steps to generate the above error consistently ? I might be able to find another way to catch if it's likely to happen through workspace storage files. Another way is to just read the logs of the current session sent from the language server : https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/d8643fce217162487a03cfadfe90e4dbacbe6a5a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/LogHandler.java#L111 and handle at

vscode-java/src/standardLanguageClient.ts

Lines 277 to 281 in d3bcbaa

	this.languageClient.onNotification(ActionableNotification.type, (notification) => {
	let show = null;
	switch (notification.severity) {
	case MessageType.Log:
	show = logNotification;

.

[rgrunber]

See #3509 .