Community
Participate
Working Groups
Due to a bug report that we got for the Spring tooling (https://github.com/spring-projects/sts4/issues/593) I analyzed the marker resolution mechanism a bit to see what is going on here. To me it seems like the mechanism that is used in LSPCodeActionMarkerResolution.checkMarkerResoultion at the end first sets the COMPUTING attribute to the marker, then triggers the computation of the code actions for the marker via the language server - and returns after this computation completed (or times out). Then, the marker attribute is changed from the COMPUTING to the actions in an async action. That results is that on first invocation, the marker resolutions are most likely "COMPUTING..." (because the async "set actions to marker" hasn't beed executed yet) and that "COMPUTING..." doesn't get changed on the UI. You have to invoke the quick fix action again. Then it shows up the right actions, since they got added to the marker in the meantime. I thought about fixing this my including the "set actions to marker" future in the timeout instead of the codeAction future, but I am worried about this not being executed if a timeout occurs on one of the codeAction futures. Any thoughts on this? Or should we instead update the quick fix popup as soon as actions are set to a marker - in case that is possible?
This piece of code can definitely be improved and be made more reactive. Setting the "COMPUTING" resolution might be useless: we could instead just store the future that computes the IMarkerResolutions and return either future.get(100) -10 milliseconds seems like an acceptable delay for that as the main UI workflows to get the quickfixes already involve hovering and typing a few keystroke to get out of pure edition flow-, or in case of TimeoutException return the "COMPUTING" and in case of other exception return an error information.
Thanks for the details, I will take a deeper look and come up with a patch.
Eclipse LSP4E is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/lsp4e/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest LSP4E snapshots (from https://download.eclipse.org/lsp4e/snapshots ) if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present with snapshots: * Create a new issue at https://github.com/eclipse/lsp4e/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed soon. Then the Bugzilla component for LSP4E will be archived and made read-only.
Migrated to https://github.com/eclipse/lsp4e/issues/123
