nimlangserver omits the id field from JSON-RPC responses when the request id was a JSON string rather than a number. The LSP spec (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#requestMessage) allows id to be integer | string. A compliant client sending string ids will never receive matched responses, breaking all LSP features.
Cause
In lstransports.nim (or equivalent routing), the response id is only set when req.id.kind == riNumber. When kind == riString, the id is silently dropped, producing a response with no id field.
Impact
LSP4IJ (https://github.com/redhat-developer/lsp4ij) (the IntelliJ LSP client, using lsp4j (https://github.com/eclipse-lsp4j/lsp4j) internally) generates all request IDs via String.valueOf(int), producing JSON strings ("1", "2", …). With nimlangserver dropping the id, lsp4j cannot match responses to pending requests. Result: every request future hangs indefinitely, the server never transitions from "starting" to "running", and no LSP features (completion, hover, go-to-definition) work.
Fix suggestion
Handle both riNumber and riString when setting the response id, echoing whatever kind was received.
nimlangserver omits the id field from JSON-RPC responses when the request id was a JSON string rather than a number. The LSP spec (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#requestMessage) allows id to be integer | string. A compliant client sending string ids will never receive matched responses, breaking all LSP features.
Cause
In lstransports.nim (or equivalent routing), the response id is only set when req.id.kind == riNumber. When kind == riString, the id is silently dropped, producing a response with no id field.
Impact
LSP4IJ (https://github.com/redhat-developer/lsp4ij) (the IntelliJ LSP client, using lsp4j (https://github.com/eclipse-lsp4j/lsp4j) internally) generates all request IDs via String.valueOf(int), producing JSON strings ("1", "2", …). With nimlangserver dropping the id, lsp4j cannot match responses to pending requests. Result: every request future hangs indefinitely, the server never transitions from "starting" to "running", and no LSP features (completion, hover, go-to-definition) work.
Fix suggestion
Handle both riNumber and riString when setting the response id, echoing whatever kind was received.