Support ServerCancelled on more request.

[ljw1004]

How can a language server decline to answer a request for the time being (e.g. because it's not ready), but without popping up a message-box?

Currently we are responding with RequestCancelled because this is the only error-code that VSCode won't pop up a message-box for. But it's an abuse: this is not what the spec says this error-code is for.

For instance, autocomplete. If the user wants member-autocomplete x.|, showing all the members available on x, then a language server can answer this pretty soon after initialization. But if the user wants global-autocomplete const x = new | then the language server needs to index every top-level symbol that appears in the entire project before it can give a definitive answer. In a project of 500k files, this indexing can easily take 1min+. It would be wrong to deny member-autocomplete for that full 1min.

Therefore: the language server wants to receive all autocomplete requests from fairly soon on, but for some of them (based on its own internal processing) it wants to decline to answer. Moreover that "decline-to-answer" shouldn't pop up a message-box. It would be intolerable to have a message-box appear for every keystroke after const x = new |.

The language server could respond with an empty autocomplete answer for when it's not ready. Or, in the case of global-autocomplete, it could respond with a partial answer that includes all the top-level symbols that it has found so far. But this is scary -- we have no idea whether VSCode will cache the empty answer, and we need a guarantee that it won't.

[dbaeumer]

The error code RequestCancelled is supposed to be used by the server if the client canceled the request and the server doesn't want to return any data. In this case the VS Code LSP client will return a proper default value to VS Code.

Since 3.17.0 there is ServerCancelled but this can only be used for request that support server cancellation. If a request is supported, then the client will re-send the request. Code completion is not yet support for server-based cancellation. Sematic tokens does support this.

What you want to achieve is currently not supported in LSP. We can either look into adding such a support or you create your own client calls and override handleFailedRequest which is called for every request that failed. You would still need to return a proper default value depending on the type of the request.

[dbaeumer]

Let me know what you think

[r3m0t]

Have you tried just not sending any answer? Is the issue that VS Code is showing a loading indicator.

LSP can handle multiple requests at a time, even while you didn't answer an autocomplete in one file, the client can still send a request for autocomplete if the user starts typing in another file (or another character in the same file).

[ljw1004]

You would still need to return a proper default value depending on the type of the request.

If we need to provide a default value, we might as well do it on the LSP server which will be easier, rather than the client. But the same basic need remains -- we need a guarantee that the "default value" we provide will not be cached by any consumer.

Have you tried just not sending any answer?

Oh! I'd never thought of that! Let me see how it works out. I always felt a bit scared of VSCode having too many open requests, but maybe it doesn't mind, and maybe it will end up sending $/cancel for earlier requests extensively enough not to be a worry.

[dbaeumer]

You should definitely be able to keep the request open. It is a good suggestion. However, you should make sure you correctly react to VS Code cancel the request. IF VS Code for example requests code complete and then the user continues typing VS Code will cancel the request and your server should correctly handle that. Otherwise, we will have too many requests open.

[mroch]

I looked into doing this a couple years ago and the details are fuzzy, but I think the problem with keeping the request open is that some language services wait for all providers to answer before showing results (completion I think, and definitely hover before 1.63). We'd break other extensions if we did this.