"Find References" triggers textDocument/didOpen but no textDocument/didClose, even after opening and closing the file

[KevinEady]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.86.2 (Universal)
• OS Version: macOS 14.0 (23A344)

Steps to Reproduce:

1. Use "Find references" that returns references that will publish diagnostics from textDocument/didOpen.
2. Open a file from the References pane that has published diagnostics.
3. Close the file, and the diagnostics for that file are still in the Problems pane.
4. Remove the result from the References pane, and the diagnostics for that file are still in the Problems pane.

Sample repository with a minimal reproduction and additional steps: https://github.com/KevinEady/vscode-bug-no-didClose

The extension clears published diagnostics in the textDocument/didClose handler (as seen when file1.txt closes), see here. Since the diagnostics for the files in the References pane never clears, I can only assume there is no textDocument/didClose event triggered for these files. Enabling the LSP debug logs via "escript.trace.server": "verbose" confirms this assumption.

It seems impossible to remove these diagnostics, as the textDocument/didClose never triggers, even after opening the file.

[VSCodeTriageBot]

The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our issue reporting guidelines.

Happy Coding!

[jrieken]

Please use vscode.window.tabGrous to know when editor tabs change. Tabs are a view-concept and they don't correlate with document lifecycles. The editor decides when documents are closed

[KevinEady]

Hi @jrieken , can you provide a little more context to how this would be done? This vscode.window.tabGroups seems like something that needs to be done within the "client extension" part itself, and not the Language Server. How can I clear diagnostics from within the client extension itself? Do I need to listen to the "tab closed event" inside the client extension, then send a notification to the LSP server, then have the LSP server respond with clearing the diagnostics?

[KevinEady]

Additionally, which editor event can I use to listen to the "Reference Cleared" event, ie. when the user clicks any of these buttons:

I will need to clear the diagnostics for these files when the reference is removed, since the user may not open a tab for the corresponding file and the diagnostics would stay in the Problems pane indefinitely.

[jrieken]

Do I need to listen to the "tab closed event" inside the client extension, then send a notification to the LSP server, then have the LSP server respond with clearing the diagnostics?

I am no LSP expert, but likely "yes"

[jrieken]

I will need to clear the diagnostics for these files when the reference is removed, since the user may not open a tab for the corresponding file and the diagnostics would stay in the Problems pane indefinitely.

There is no such event. I believe you don't want create diagnostics to begin with - only for tabs

[KevinEady]

Thank you for your help... I will try that then.

FWIW, the Microsoft LSP sample sends diagnostics on textDocument/didOpen and textDocument/didChange: https://github.com/microsoft/vscode-extension-samples/blob/be3ef98e19fca4714a1d73fa5bd7181eb9d70354/lsp-sample/server/src/server.ts#L131-L135

It sounds like this implementation is incorrect then, at the very least misleading.

[jrieken]

yes, looks like it didn't get updated when we added the tabsGroups-api.

fyi @dbaeumer

[KevinEady]

Hi @jrieken ,

I finished my investigation and this tab group events do not seem to be the correct way:

    window.tabGroups.onDidChangeTabs(e => {
        const toLabels = (tabs: readonly Tab[]) => tabs.map(tab => tab.label);
        console.log(`onDidChangeTabs. Changed: ${toLabels(e.changed)} Opened: ${toLabels(e.opened)} Closed: ${toLabels(e.closed)}`);
    });

1. The event is not fired on initial opening of the window. Naturally we want diagnostics for the documents that exist when the window opens.
2. I'm not sure how to receive the full filesystem path (or URI) for the given tab? Tab.label only contains the file name, excluding the path (eg. file1.txt) This doesn't help as I would need the full path. I understand that not all tabs correspond to filesystem paths (eg. files that have not been saved yet), but my Language Server can only process existent files, so no need to worry about unsaved tabs.

And another thing. You mentioned:

Tabs are a view-concept and they don't correlate with document lifecycles. The editor decides when documents are closed

Can you tell me when the editor would decide to close a document that's been opened from the references pane (without the tab being opened, as shown in the original post's video above)? Maybe I'm missing something, but I can't really understand why the editor would consider the document open if there is no tab and the reference has been cleared from the Reference Pane. It seems the editor considers the document opened indefinitely, as opening a corresponding tab and closing the tab + clearing the references does not trigger textDocument/didClose, so ... the editor must have some reason to consider the document open, and I'm not sure what it is. If I can understand this, then I may have a different solution, which could just be as simple as some user interaction (eg. "click ").

Again, thank you for your assistance and quick response times. I greatly appreciate it!

[jrieken]

I'm not sure how to receive the full filesystem path (or URI) for the given tab?

Use Tab.input

Can you tell me when the editor would decide to close a document that's been opened

No, just accept that editor decides but note that document != editor != tab

[KevinEady]

Thanks for the insight with Tab.input! After seven hours of back-and-forth various implementations, I think I have a good workaround, in case anyone else stumbles upon this issue:

1. On server start (via client.onDidChangeState), as well as on tab change, send a list of open tabs to LSP server.
2. In LSP, only send diagnostics for documents that have an open tab.
3. On tab change inside LSP, clear diagnostics for closed tabs, and send diagnostics for new tabs.

I think this covers all my use-cases.

Thanks for all your assistance today 🙇

[dbaeumer]

@KevinEady just see the issue now. Was out on vacation. Actually LSP has full support for diagnostics only for files that are open in tabs. Instead of letting the server push the diagnostics you can let the LSP client pull for diagnostics. The client will then do all the tab handling, editor focus switching, ... for you. For the documentation see: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_pullDiagnostics

One of the reasons to introduce the pull model was to avoid syncing the tab model to the server since it is nothing the server should be concern about.

[KevinEady]

Thanks for the insight @dbaeumer ! I was able to successfully change my implementation, removing this "send open tabs" workaround and relying solely on the textDocument/diagnostic message 👍