Empty JSON objects in LSP responses interpreted as null when lsp-use-plists is non-nil

[ProjectFrank]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• I checked FAQ and Troubleshooting sections
• You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

Responses sent by a language server containing {} are interpreted as null. When interpreting the capabilities field of the initialize response, this causes lsp-mode to think that a capability is not supported when it actually is.

In my own use case, the language server is responding with the following:

{
  "capabilities": {
    "textDocumentSync": {
      "openClose": true,
      "change": 2
    },
    "completionProvider": {}
  },
  "serverInfo": {
    "name": "tabby-agent",
    "version": "1.3.3"
  }
}

lsp-mode interprets the value under the completionProvider field as null, which prevents lsp-mode from asking the language server for completion suggestions.

Steps to reproduce

1. Follow these steps to use plists for deserialization.
2. Use a language server that sends back a {} in its initialization response.
3. Set lsp-log-io to t.
4. Start the language server via lsp-mode.
5. Use lsp-workspace-show-log to show the log.
6. Inspect the initialize response and confirm that a null appears instead of {}.

Expected behavior

Rather than null appearing, the io log should show {}. This is the case when lsp-use-plists is nil.

Which Language Server did you use?

This happens when using tabby-agent. The language server's initialize response is:

{
  "capabilities": {
    "textDocumentSync": {
      "openClose": true,
      "change": 2
    },
    "completionProvider": {}
  },
  "serverInfo": {
    "name": "tabby-agent",
    "version": "1.3.3"
  }
}

OS

MacOS

Error callstack

No response

Anything else?

No response

[Souheab]

Can confirm that I am experiencing this issue as well on Arch Linux on emacs 29.2.