Offer users an extension downgrade if certain failure conditions detected.

[rgrunber]

Suppose we intend to introduce some functionality that will benefit most users, but after release, we realize it breaks for 5-10% of users. I've seen people try downgrading to a previous version. That alone is useful when tracking the problem and works well enough for them. However, I wonder how many users encounter the breaking issue, and don't know what to do, or might stop using the extension.

If the issue can't be immediately fixed, and we don't want to (can't) revert the change could we use some kind of issue detection (stacktrace/condition in LS or client itself) in a subsequent service release, and then offer the user a downgrade to the last safe version ? Then just perform :

commands.executeCommand("workbench.extensions.installExtension", `redhat.java@${safeVersion}`);

To avoid having to do a release, would it make sense to have some kind of publicly defined file that maps between expected errors and the corresponding downgrade to propose ?

I don't feel that strongly about this (so I'm fine with just closing), but a lot of regressions can be quickly solved by a downgrade, and making the process more user-friendly would be nice.

CC: @testforstephen @fbricon for thoughts.

[testforstephen]

I agree that we should offer some guidance to users when they encounter fatal errors. However, the current problem is that Java extension does not have a reliable way to monitor the tooling health status. The server status is hidden from users, and there is no clear sign of whether the server is crashed or malfunctioning. They often spend a lot of time troubleshooting before they find out that the Java extension is not working properly.

Therefore, I suggest that we improve the server status monitor first and make it more accurate. This way, users can have a better awareness of the extension’s state and take appropriate actions to solve the problem.