LSP assumes JSON-RPC IDs are integers

Bug Reports
1

I’m working on an extension for the serve-d D language server, I see this:

D Language Server[17:01:17.928000] JSON-RPC could not decode message: typeMismatch(Swift.Int, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: “id”, intValue: nil)], debugDescription: “Expected to decode Int but found a string/data instead.”, underlyingError: nil)) Content-Length: 192

{“jsonrpc”:“2.0”,“id”:“cVv61MEir2ZvO2”,“method”:“workspace/configuration”,“params”:{“items”:[{“section”:“d”},{“section”:“dfmt”},{“section”:“dscanner”},{“section”:“editor”},{“section”:“git”}]}}

JSON-RPC permits strings (and even null!) to be used for the id. I’m working with the developer of serve-d to see if he can change this, but really this assumption is bogus in Nova.

2

Hello Garrett,

Thank you for bringing this to our attention.

From reading the JSON-RPC documentation:

An identifier established by the Client that MUST contain a String, Number, or NULL value if included.

The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects.

Since Nova is the client in this scenario, and the language server is the server, from reading this it’s up to Nova to decide whether to use an integer or a string. Up until now, every language server we’ve encountered uses integers.

We’ll consider this a feature request for the future, perhaps with some way to indicate to the LanguageClient instance in JavaScript that the language server does not support integers and to talk to it with strings instead.

3

The issue is that when the server issues a notification to the client, it can choose it’s own identifier because it is initiating the request.

This broke earlier versions of Serve-D, but I got the language server developer to switch to using identifiers. Still it would be good not to assume this for notifications.