Testing `textDocument/didClose` in extensions requires a three minute timeout

When opening a file in tests using vscode.workspace.openTextDocument followed by vscode.window.showTextDocument and closing it again using workbench.action.closeAllEditors or workbench.action.closeActiveEditor, a textDocument/didClose notification is not fired until three minutes have passed since the file was opened. I assume this happens for the same reason as the three minute timeout in #652.

While it’s possible to test functionality that depends on a didClose notification with a three minute pause, it’s not ideal. Is there a way to open (or close) files in extension tests that fires the notification sooner?

In case it helps, I’ve also put together a small reproducer. Just compare the behavior of manually opening foo.txt in the file tree and closing it after the language server has started with what the test does.

Tested on VS Code version 1.70.2.

[dbaeumer]

didOpen and didClose fire when an editor (e.g. VS code) reads the content of a file into a buffer. They fire even if the buffer is not presented in a editor. For example if you run a rename refactoring VS Code loads lots of buffers into memory to apply the text edits. This case open/close events even though these documents are not visible in the UI.

The pull diagnostic feature doesn’t pull for diagnostics for documents that are not visible in the UI assuming that the user is not of interest for them.

Pull diagnostics is a relatively new feature and we started to port our servers over to that feature.

[DanTup]

I have ideas how to fold these open/close events however we need to ensure that this code handles all cases right

It’d be great to fix here, but it’s disappointing that it needs working around here. I don’t understand why VS Code doesn’t handle this better (eg. let an extension know if it’s opening a file only to read the contents and immediately close it for its own use - like populating the hover - where an extension/server very likely does not care about).

Regarding the three minute timeout: have you opened an issue against VS Code itself and explained the problem with testing. The underlying problem seems to exist outside of LSP as well.

Yeah, I’ve filed many issues like this about things being hard to test in VS Code. Usually the response is that I shouldn’t be integration testing, and should just test providers etc. individually (although I disagree with this, because my integration tests have caught many issues - both my own and VS Code’s that testing the providers would not have caught). For this particular issue, all issues about it were closed as dupes of https://github.com/microsoft/vscode/issues/15178 (which helps for some cases, although not really for getting a clean state for integration tests without new workspaces).