Server fails on unknown enum values #438
Comments
|
This issue stems from the fact we rely on However, in the meantime, you should be able around this issue by providing your own customised Using the following code I was able to resolve the errors thrown by the extra from lsprotocol import types
from pygls.protocol import default_converter
from pygls.server import LanguageServer
def my_converter():
converter = default_converter()
def completion_item_kind_hook(obj, type_):
try:
return types.CompletionItemKind(obj)
except ValueError:
return obj
converter.register_structure_hook(
types.CompletionItemKind, completion_item_kind_hook
)
return converter
server = LanguageServer("example-server", "v0.1", converter_factory=my_converter)Any unknown values will now show up as a plain I imagine a similar approach will also allow you to resolve the issue with |
|
It's probably worth mentioning though, that depending on if you intend to use these values in messages yourself you could run into other issues - I had to use a few hacks in my code to reproduce your error.... # Override the type lookup mechanism
get_type = client.protocol.get_message_type
client.protocol.get_message_type = lambda m: (
JsonRPCRequestMessage if m == "initialize" else get_type(m)
)
response = await client.protocol.send_request_async(
"initialize",
dict(
capabilities=dict(
textDocument=dict(
completion=dict(
completionItemKind=dict(
valueSet=[
# fmt: off
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 118115,
118116, 118117, 118118, 118119,
118120, 118121, 118122, 118123,
118124, 118125, 118126,
# fmt: on
]
)
)
)
),
root_uri=uris.from_fs_path(root_dir),
),
) |
|
Thanks for the super quick response! I can confirm that the suggested workaround does solve the problem for me! I'm not really interested in the additional, proprietary values. IMO it's a bit strange that Visual Studio is sending them in the first place, because for them to have any semantic meaning the language-server would need to know that it is connected to Visual Studio? 🤔 |
Visual Studio is sending unexpected values for CompletionItemKind and DiagnosticTag. This workaround fixes interoperability with Visual Studio, a permanent solution might be coming soon: openlawlibrary/pygls#438
I am currently trying to connect to my Pygls server from Visual Studio.
Unfortunately Visual Studio is sending unexpected values for
CompletionItemKindandDiagnosticTagin theinitializemessageContents of the JSON initialize message (trimmed)
{ "traceparent": "00-54539a4a40ff3248a03ded63822bdf1a-cda15417ab88d44d-01", "jsonrpc": "2.0", "id": 2, "method": "initialize", "params": { "capabilities": { "textDocument": { "completion": { "completionItemKind": { "valueSet": [ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 118115, 118116, 118117, 118118, 118119, 118120, 118121, 118122, 118123, 118124, 118125, 118126 ] } }, "publishDiagnostics": { "tagSupport": { "valueSet": [ 1, 2, -1, -2 ] } } } } } }Pygls then raises an exception when processing the message, because values like
118118do not exist in theCompletionItemKindenum and-1is not a knownDiagnostigTag.Error report
In case of the
CompletionItemKindit seems like the Visual Studio Client is promoting some proprietary completion item types to the language server. The meaning of the additionalCompletionItemKindis documented here.In the LSP Specification, the handling of unknown values is specified as follows:
Based on this information I would expect Pygls to ignore the additional values that Visual Studio is sending, and not fail with an exception.
Reproducing the exact problem could be a bit complicated, as it requires setting up a Visual Studio extension that launches a Pygls language server. I can provide an MVP if requested.
The text was updated successfully, but these errors were encountered: