Is this reported upstream? Also, can we replace this one with a local patch(e. g. check only if :items are present to determine the type of the object) instead of introducing the patch on the global level?

@yyoncho this is more-or-less a local patch: lsp-interface is extended to support semi-required fields, and the only interface definition that changes is CompletionList, which now doesn't require :isIncomplete to be present. All other interfaces are completely unaffected.

I don't know whether this can be raised upstream - I cannot submit a PR, given that iph is proprietary.

lsp-interface part of the public lsp-mode's interface so it is not local.

My change doesn't break anything - all previous uses of lsp-interface will still continue to work like they did, if the use triples. This is because -let + list destructuring sets variables to nil if the list ends first (expanding to pop, which supports variables that are nil):

(funcall (-lambda ((a b c d)) d) '((a))) ; nil, not error, even though we are missing three elements
(let (foo) (pop foo)) ; nil
(pop nil) ; error: setf nil

That also means that interface triples can also be pairs, or even one-tuples.

The issue is that we add a parameter that makes little sense and it is hard to explain. Using vectorp instead of lsp-completion-list? will fix the code too and it won't introduce awkward changes to public lsp-mode functions.

Using vectorp instead of lsp-completion-list? will fix the code too and it won't introduce awkward changes to public lsp-mode functions.

I think we will actually need to check for items is presented in response from server to fix this error.

Anyway, this is clearly spec violation, and the more we support those behaviors, the more our code become unmanageable. Extending the interface to accommodate the kind of semi-optional is not making sense too.

We can actually ask the user of iph to actually advice the lsp-require-while-no-input to specially insert the isIncomplete field into textDocument/completion response. That requires no hack from lsp-mode (so we keep spec compliant) and discourage from using spec violated language server.
If you pay for iph, you should have the rights to file bug and ask for its changes to compliant with actual specs.

I think we will actually need to check for items is presented in response from server to fix this error.

This is what I initially suggested. Spent some time analyzing the code and you will end up with the conclusion that using vectorp is much easier to implement.

Ah, yes, that would work too.

Ah, yes, that would work too.

The issue is with the merge function and we do not expose member func via lsp-protocol.el.