Always pull diagnostics on didOpen even if document is already known via tab#1719
Draft
Always pull diagnostics on didOpen even if document is already known via tab#1719
Conversation
… tab When a document is restored from a tab (e.g., hot exit), the tab open event fires before the didOpen notification. The tab handler triggers a diagnostic pull with potentially stale content. Previously, when didOpen fired, the knows() check would skip re-pulling diagnostics. Now the didOpen handler always triggers a diagnostic pull. The existing pullAsync logic handles deduplication - if a request is already active, it cancels it and reschedules with the current document content. Fixes #1558 Co-authored-by: dbaeumer <1931590+dbaeumer@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Fix client requests for diagnostics before didOpen
Always pull diagnostics on didOpen even if document is already known via tab
Feb 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When tabs are restored (e.g. hot exit, restart), tab events fire before
textDocument/didOpen. The tab handler triggers a diagnostic pull with disk content, then thedidOpenhandler'sknows()check skips re-pulling—so diagnostics are never recomputed with the actual document content (which may include unsaved changes).knows()early-return guard in thedidOpenhandler so it always triggers a diagnostic pullpullAsyncalready handles concurrent requests correctly: if a pull is in-flight, it cancels and reschedules with current contentOriginal prompt
This section details on the original issue you should resolve
<issue_title>Client requests textDocument/diagnostics before textDocument/didOpen</issue_title>
<issue_description>I don’t know how to reproduce this reliably in a fresh repo, but it’s happening every time I restart the language client/server in my window right now. In the logs, you can see two
textDocument/didOpen, followed bytextDocument/diagnosticforfile:///Users/andrew/Developer/microsoft/typescript-go/Herebyfile.mjs, which is not one of the two that's been already opened. ThetextDocument/didOpenfor Herebyfile.mjs comes later (very end of the logs pasted), and after that, there’s no subsequenttextDocument/diagnosticrequest for it. This must be a bug, because I have unsaved changes in that file's editor, so thedidOpencontent is going to be different from the text on disk, which is the only thing we could access in order to compute diagnostics.This actually causes us (TypeScript) to return an error, because from observation we counted on the client only asking for diagnostics for files it’s already opened. But even if we gracefully served the request, the diagnostics shown would be for the wrong content.