Inconsistent response of Pyright languague server

[MarkBekooy]

For my project, I'm faking to be a code editor by sending my own LSP commands to the Pyright language server.
For this, I follow the LSP specification.

This works! Great. However, I had to make a change to my code and that suddenly broke the response I got back from the Pyright language server.

Working LSP command

Message:

SENDING: {"jsonrpc": "2.0", "id": 0, "method": "initialize", "params": {
"capabilities": {"workspace": {"apply_edit": true, "workspace_edit": {"document_changes": true}, "workspace_folders": true}, "textDocument": {"synchronization": {"dynamic_registration": true}, "publish_diagnostics": {"related_information": true}, "diagnostic": {"dynamic_registration": true, "related_document_support": true}}},
"processId": 26576,
"rootPath": null,
"rootUri": "file:///D:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated",
"workspaceFolders": [{"name": "type-annotation-searcher", "uri": "file:///D:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated"}],
"trace": "verbose"}
}

Response:

{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Pyright language server 1.1.316 starting'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Server root directory: C:\\Users\\markb\\.cache\\pyright-python\\1.1.316\\node_modules\\pyright/dist/'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Starting service instance "type-annotation-searcher"'}}

SENDING: {"jsonrpc": "2.0", "method": "initialized", "params": {}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': "Loading configuration file at d:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated\\pyrightconfig.json"}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Assuming Python version 3.10'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': "No include entries specified; assuming d:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated"}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Auto-excluding **/node_modules'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Auto-excluding **/__pycache__'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Auto-excluding **/.*'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Found 69 source files'}}

And now the configuration file gets properly loaded.

Problem

Notice the workspace_folders and workspaceFolders properties. In my new code, I cannot have the workspace_folders as snake_case anymore. It must also become workspaceFolders. And this suddenly breaks the Pyright LSP response.

Not working LSP command

I just changed the workspace_folders into workspaceFolders
Message:

SENDING: {"jsonrpc": "2.0", "id": 0, "method": "initialize", "params": {
"capabilities": {"workspace": {"apply_edit": true, "workspace_edit": {"document_changes": true}, "workspaceFolders": true}, "textDocument": {"synchronization": {"dynamic_registration": true}, "publish_diagnostics": {"related_information": true}, "diagnostic": {"dynamic_registration": true, "related_document_support": true}}},
"processId": 26576,
"rootPath": null,
"rootUri": "file:///D:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated",
"workspaceFolders": [{"name": "type-annotation-searcher", "uri": "file:///D:\\Documents\\TU Delft\\Year 6\\Master's Thesis\\lsp-mark-python\\src\\typeshed-mergings\\redis-correct\\fully-annotated"}],
"trace": "verbose"}
}

Response:

{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Pyright language server 1.1.316 starting'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Server root directory: C:\\Users\\markb\\.cache\\pyright-python\\1.1.316\\node_modules\\pyright/dist/'}}
{'jsonrpc': '2.0', 'method': 'window/logMessage', 'params': {'type': 3, 'message': 'Starting service instance "type-annotation-searcher"'}}

SENDING: {"jsonrpc": "2.0", "method": "initialized", "params": {}}

Since the configuration file is now not loaded, all other steps of my algorithm also fail, so I hope that there is a solution to this.

[erictraut]

workspace_folders isn't a valid capability according to the LSP spec, so the first message above is invalid. The second message fixes this bug, but it still contains other invalid capability names. Capability names within the LSP are all camel-cased. Refer to the LSP spec for details.

Pyright honors the capabilities provided by the client. If you don't specify "workspaceFolders": true, then it will assume that the client doesn't support the workspace folders capability, and it will use the rootUri as the single workspace.

It sounds like you're new to the language server protocol. You may find it useful to look at other LSP clients and follow their example. Compare your messages with the messages they send.

Pyright has not been tested with all combinations of LSP capabilities, so it's theoretically possible that you could run into bugs with certain combinations. I recommend sticking with sets of capabilities that are supported by VS Code or other major LSP clients. If you suspect that you have found a bug in the handling of a particular combination of capabilities, I'll ask that you do additional legwork to diagnose the problem in pyright. Its source is available, and there are instructions for building and debugging it.

[MarkBekooy]

Thanks for your comment! I'm indeed new to the language server protocol, but I am familiar with the convention of names within the LSP to be all camel-cased. However, although I didn't use camel-casing (see message 1) I got a result back that worked, so I was happy. Now, it turns out that I sent "workspace_folders": true, but since workspace_folders is an invalid property, it was excluded and thus it was indirectly assumed that "workspaceFolders": false which ultimately made my code work. Okay, I didn't expect that, but discovered it because of your comment, so thank you very much!

Now I'm sending the proper camel-cased properties as a message and omitting "workspaceFolders": true (although I could set it to false, if I were to include it), and now my code still works, so that is great!