[lahodaj]

Currently, TextDocumentServiceImpl.codeActions stores the lazy actions in a "cache", so that later resolveCodeAction can get the lazy action instance back. But, there's a problem (or a group of problems): codeActions clears the cache at the beginning, and resolveCodeAction blindly reads from the cache list. As a consequence, resolveCodeAction may either crash with an IndexOutOfBoundsException, or (even worse) resolve the action with data from a different action from a different codeActions run.

The proposal herein is to use "slots" to store the cached actions, so that calling codeActions, then codeActions again, and then resolveCodeAction on an action from the first call should still work. The cache now allows two elements, which feels sensible due to the asynchronous nature (the outcomes of codeActions that finished for the server may not reach the client before the client issues resolveCodeAction).

If the resolve query is for an evicted slot, the resolve request is silently ignored - if desired, it would be possible to complete the future exceptionally.

The slots are identified by ints. There's still a theoretical possibility of interference if the slot ID would wrap over, but it seems highly unlikely the UI would store code actions for ~2^32 codeActions invocations and then still resolve the actions.

See also oracle/javavscode#652

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

LLMs, Commit messages and PR description:

• Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
• LLM assisted commits should be attributed with an Assisted-by: MODEL_NAME MODEL_VERSION line appended to the commit message.
  • Please mention coding assistance in the PR description too (eg. by adding the same Assisted-by line from above)
  • Please describe the changes in your own words - we'd like to know you understand the changes being made!

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[dbalek]

Looks fine.