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. Alternatively, it might be that build or update is called without wrapping it inside of a WorkspaceLock#write.

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.

[Greglar4]

Hi @msujew , coworker of @jmenzies12 here.

The break point you pointed out seems to always be guarded by an await workspaceManager.ready call.

I was wondering if you could point me to a place to put a breakpoint when either of the errors are thrown:

[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).

or

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

I was thinking if we pause only on these errors we could inspect the call stack only when those errors happen.

I tried searching the Langium repository for key substrings of these error messages, but I can't seem to find them.

Thanks,

Greg

[msujew]

The errors originate here and here. I would recommend focusing on the latter, since the former is likely just a consequence of the document failing to update correctly.