0.28.8: malformed JSON response to initialize message

[siegel]

Using 0.28.8, the JSON that comes back from an initialize message looks like this:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "capabilities": {
            "textDocumentSync": {
                "openClose": true,
                "change": 2,
                "willSave": false,
                "willSaveWaitUntil": false,
                "save": true
            },
            "completionProvider": {
                "triggerCharacters": [
                    ".",
                    "'",
                    "\""
                ],
                "resolveProvider": true
            },
            "hoverProvider": true,
            "signatureHelpProvider": {
                "triggerCharacters": [
                    "(",
                    ","
                ]
            },
            "declarationProvider": null,
            "definitionProvider": true,
            "typeDefinitionProvider": null,
            "implementationProvider": null,
            "referencesProvider": true,
            "documentHighlightProvider": true,
            "documentSymbolProvider": true,
            "codeActionProvider": {
                "codeActionKinds": [
                    "refactor.inline",
                    "refactor.extract"
                ]
            },
            "codeLensProvider": null,
            "documentLinkProvider": null,
            "colorProvider": null,
            "documentFormattingProvider": null,
            "documentRangeFormattingProvider": null,
            "documentOnTypeFormattingProvider": null,
            "renameProvider": true,
            "foldingRangeProvider": null,
            "executeCommandProvider": {
                "commands": []
            },
            "selectionRangeProvider": null,
            "workspaceSymbolProvider": true,
            "workspace": {
                "workspaceFolders": {
                    "supported": true,
                    "changeNotifications": true
                }
            }
        }
    }
}

The null values for declarationProvider and others aren't correct. According to the spec, those values should be true or false, and null isn't translatable to a Boolean.

Because those keys are optional, it may be better to omit them entirely rather than reporting null; but if that's not an option, false is probably a better choice.

This appears to be a regression from previous versions, which omitted those keys.

[pappasam]

Would you be able to provide me a full log of requests / responses up until that point? I've just added TCP support, so this will now be easier for me to test out on the command line.

Note: this may be an issue with pygls; I don't believe jedi-language-server does anything special with the initialize response. If this turns out to be the case, would you be able to open an issue in that repo and link to this one?

[dimbleby]

This is certainly one for pygls:

• here is where it serializes messages, note that it does have exclude_unset=True, which mostly is enough to stop pygls from setting unwanted "null"
• but it always explicitly sets these particular fields eg here, so they don't get skipped

I expect that the right fix is to rework the pygls code so that it only explicitly sets these fields when it has a value to set them to, eg perhaps they want something like

    def _provider_options(self, field, feature, default=True):
        if feature in self.features:
            value = self.feature_options.get(feature, default)
            setattr(self.server_cap, field, value)

which is certainly uglier, but works better.

(An alternative try would be to exclude_none=True at serialization but I think that's too broad, there are non-optional fields in the protocol where null has meaning, so nuking them all is going too far.)

[dimbleby]

pygls fix is now released in their 0.10.3

[pappasam]

@siegel has this been resolved in 0.10.3? That version is compatible with the latest release of jedi-language-server so you can test it right now!

[siegel]

@pappasam Yes! It appears to be resolved; I'm not seeing any null values coming back.