Timing issues with Language Server events (particularly on Windows)

[jmenzies12]

Hey there,

We've been running into a couple of issues that appear to be due to the timing of events happening for Langium documents in VSCode. Wondering if anyone else has run into these? Particularly it seems to happen on Windows versions of VSCode.

First issue is when opening a workspace and creating a new file tied to a language we immediately get the following error

[Trace - 7:40:17 AM] Received response 'textDocument/codeAction - (5)' in 22ms. Request failed: Document state of file:///c%3A/Users/***/new_req_table.requirement is Parsed, requiring Validated, but workspace state is already Validated. Returning undefined. (-32803).

Doing the same operation can also result in the following error

ERR Request textDocument/documentSymbol failed with message: A document with the URI ‘blah’ is already present

Cheers
Jonathan

[msujew]

Hey @jmenzies12,

we have an issue tracking this already, see #2104. I'll take a look at this soon.

[jmenzies12]

Hey @jmenzies12,

we have an issue tracking this already, see #2104. I'll take a look at this soon.

Okay great! Thank you

[msujew]

@jmenzies12 I just had time to have a closer look at #2104. #2114 should fix that specific issue, but it will likely not fix your issue. As far as I can tell after debugging #2104, this is not a framework issue. Instead, something in your language server is likely calling DocumentBuilder.build before WorkspaceManager.ready is resolved.

Can you try to confirm this? I found it pretty easy to reproduce and debug by doing the following:

1. Set the DEBUG_BREAK env variable to "true" in your vscode launch config to ensure that the language server only starts once the debugger is connected.
2. Set a breakpoint here.
3. Perform whatever you usually do to reproduce the issue.
4. Attach the debugger to the language server. It should now start up.
5. The debugger should rather quickly arrive at the breakpoint mentioned above.

The callstack should show you now what is calling the build. This code path should be guarded by a await workspaceManager.ready call, as seen in #2114.