Marker resolutions "Computing..." not being updated automatically

[BoykoAlex]

Due to a bug report that we got for the Spring tooling (spring-projects/spring-tools#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?

Due to a bug report that we got for the Spring tooling (spring-projects/spring-tools#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?

[BoykoAlex]

@martinlippert asked me to look into this issue... Don't think I have a good idea how to fix it... I've created a hack to listen to MarkerAnnotationModel changes on MarkerResoltionQuickAssistProcessor from generic editor and if the changed marker annotation is one of those for which resolutions are currently shown then I'd execute quick assist op on the current editor.... it worked but this solution has plenty of "weak links"

1. The marker is indeed changed once resolutions (code actions) are fetched from the LS, however this doesn't result in annotation model change since marker positions is unchanged - hacked eclipse editors plugin to send the event anyway
2. Not sure how can i tell if the pop up with proposals is gobe or still up when i receive the annotation model change event in MarkerResoltionQuickAssistProcessor

If @mickaelistria or @martinlippert had any ideas or plans for this issue please share :-)

[mickaelistria]

Is the main issue for hover or for Ctrl+1 ?

[BoykoAlex]

Both are having the issue but I think Ctrl-1 is the only case I've been trying to fix...

[mickaelistria]

It seems a bit tricky to navigate from the LSPCodeActionQuickAssistProcessor to the dialog that is used to render them. However, maybe it's possible to just get current shell, close it if we see it's a table that contains the "Computing..." element and then programatically re-trigger the QuickAssist?

[BoykoAlex]

@mickaelistria attached a draft PR for the review. Addresses quick assist popup and hover. Seems to work :-)