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

Send document-version-annotated diagnostics to avoid staleness #1365

Open
2 tasks
radeksimko opened this issue Aug 29, 2023 · 0 comments
Open
2 tasks

Send document-version-annotated diagnostics to avoid staleness #1365

radeksimko opened this issue Aug 29, 2023 · 0 comments

Comments

@radeksimko
Copy link
Member

Context

As part of #1346 we implemented validation jobs which run asynchronously.

As mentioned in #1346 (comment) this means that - under pressure (with enough changes/jobs in queue) - users could potentially observe outdated diagnostics as the jobs are cleared from the queue in the order they were submitted. These stale diagnostics should always eventually be overwritten by the up-to-date ones though.

Implementation Notes

LSP offers a way of associating document version numbers with published diagnostics, as per https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#publishDiagnosticsParams This would at least (in theory) mean that users are never presented with irrelevant/stale diagnostics as the client should discard diagnostics for earlier document versions (this is to my best understanding of the protocol spec, it may not work that way in practice - needs to be verified!).

Proposal

  • Look into whether we could avoid computing diagnostics entirely for outdated document versions (i.e. avoid wasting CPU/memory) - e.g. returning from jobs early if we know the job was submitted for version X and the latest known version Y is higher
  • Publish diagnostics with document version attribute (as per above)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant