Code change:
// create the suggestion resolver if (typeof provider.resolveCompletionItem !== 'function') { this._resolveCache = Promise.resolve(); <ins> this._isResolved = true; </ins> } } // resolving get isResolved() { <del> return Boolean(this._resolveCache); </del> <ins> return Boolean(this._isResolved); </ins> } private _resolveCache?: Promise<void>; <ins> private _isResolved?: boolean; </ins> async resolve(token: CancellationToken) { if (!this._resolveCache) { const sub = token.onCancellationRequested(() => { this._resolveCache = undefined; <ins> this._isResolved = false; </ins> }); this._resolveCache = Promise.resolve(this.provider.resolveCompletionItem!(this.completion, token)).then(value => { Object.assign(this.completion, value); <ins> this._isResolved = true; </ins> sub.dispose(); }, err => { if (isPromiseCanceledError(err)) { // the IPC queue will reject the request with the // cancellation error -> reset cached this._resolveCache = undefined; <ins> this._isResolved = false; </ins> } }); }

Related discussion:
text: Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.