Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: propagate LanguagServerWrapper startup exception correctly #1044

Merged
merged 2 commits into from
Sep 5, 2024

Conversation

ava-fred
Copy link
Contributor

If there is an exception in the startup of the LanguageServerWrapper, consumers get a cancellation exception rather than the actual exception that occurred. This commit fixes the problem.

Copy link
Contributor

@rubenporras rubenporras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ghentschke , this makes sense now to me. We have opened a discussion in #1093 just in case you think it is not.

/**
* @return whether the last startup attempt has failed
*/
public synchronized boolean startupFailed() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this method called by anyone? What's the purpose of this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is to determine whether a startup attempt on this LanguageServerWrapper object failed and a call to restart() is needed. We will be using it in our project.

* Starts a language server and triggers initialization. If language server is
* started and active, does nothing. If language server is inactive, restart it.
* Starts a language server and triggers initialization. If language server has been started
* before, does nothing.
*/
public synchronized void start() {
start(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an exception has been occurred during start. The LS cannot be started again when the cause has been fixed (e.g. wrong path do LS binary).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could we worth explaining as well that "an Eclipse-base product can check startupFailed and call restart if the problem has been programmatically handled", and that otherwise "once the problem is fixed a restart of eclipse is needed". That would clarify as well the need for the startupFailed method for future readers of this class. My wording can most probably be improved :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..but I am okay with it. This can/should be handled by the LS provider

* Starts a language server and triggers initialization. If language server is
* started and active, does nothing. If language server is inactive, restart it.
* Starts a language server and triggers initialization. If language server has been started
* before, does nothing.
*/
public synchronized void start() {
start(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

..but I am okay with it. This can/should be handled by the LS provider

If there is an exception in the startup of the LanguageServerWrapper,
consumers get a cancellation exception rather than the actual exception
that occurred.
With this commit, this behavior is changed. As a consequence of the
change, calls to LanguageServerWrapper.start() will do nothing after a
failure. To test for this case (and attempt a restart() if feasible),
the startupFailed() method is added.
@rubenporras
Copy link
Contributor

Thanks for the improved javadoc

@rubenporras
Copy link
Contributor

It looks like there is a need for investigation of view the CI Jenkins job fails more or less consistently. Other PRs seem to be fine in the same job, so it does not look like a infrastructure glitch.

@rubenporras rubenporras self-requested a review September 4, 2024 14:41
Copy link
Contributor

@rubenporras rubenporras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it was temporary glitch on the infrastructure.

@rubenporras rubenporras merged commit 7ce9692 into eclipse:main Sep 5, 2024
6 checks passed
sebthom added a commit to sebthom/lsp4e that referenced this pull request Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants