Quick fixes get corrupted when code actions from multiple Language Servers are relevant to one Java file.

Background

I'm working on Liberty Tools Eclipse which pulls in each of the LSP4Jakarta and LSP4MP language servers.

In this issue I noted that the Quick Fix that should be generated by the LSP4Jakarta is getting handled/produced/displayed incorrectly because of the presence of LSP4MP and its code action.

Instead of the "Quick Fix" I expect from the LSP4Jakarta code action, I see a mix of a Quick Fix from a LSP4MP code action and the LSP4Jakarta diagnostic I think incorrectly displayed (see the screenshot in the above issue in Liberty Tools Eclipse).

Environment:

• lsp4e v0.17.1 (the bundle, which I believe => v0.24.1 Git tag/release) in Eclipse v4.29, consuming LSP4MP 0.10.0 and LSP4Jakarta 0.2.0-SNAPSHOT, on Windows 11

Suspected area of code

I have debugged into the code to have a rough idea of where things might be going wrong, but still have some gaps in my knowledge.

I'm thinking this code is likely related to my problem, since it seems to be content to use the first response by the first LS (via executor.computeFirst(...)) .

The LSP4MP has a code action that is not scoped to any particular diagnostic:

     <extension point="org.eclipse.lsp4mp.jdt.core.javaFeatureParticipants">
      <!-- Java codeAction for generating MicroProfile OpenAPI annotations -->
      <codeAction kind="source"
                  class="org.eclipse.lsp4mp.jdt.internal.openapi.java.MicroProfileGenerateOpenAPIOperation" />
   </extension>

whereas the LSP4Jakarta code action is related to a specific diagnostic identified by the LSP4Jakarta.

Furthermore, this code changed was changed in this PR: https://github.com/eclipse/lsp4e/pull/535/files which was from around the time I first noticed the problem, in the v4.27 release from 1Q23. (However at the time I was running with a different level of lsp4e from the one in the standard package so I do NOT really have a "clean" bug report from the v4.27 release).

Other notes

UPDATE: I deleted my previous paragaraph here. All I was observing was that the marker had an attribute, 'lspCodeActions' with value mapping onto an LSP4MP code action, while having another attribute 'lspDiagnostic', with value mapping to an LSP4Jakarta diagnostic. I don't think this marker handling attribute merging is another issue in and of itself.

Next step

I'm continuing to look at this in the debugger, but figured I'd stop and write this up in case someone already understands the problem based on that description, and/or can share some pointers.

Start in org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/codeactions/LSPCodeActionMarkerResolution.java around lines 138-141, then review PR 535 and reproduce with LSP4MP and LSP4Jakarta actions on one Java file. Check how computeFirst and the lspCodeActions and lspDiagnostic marker attributes interact. Done means diagnostic-specific and unscoped actions are handled without corrupting the displayed quick fix.