CompletionList.isIncomplete=true results in showing "stale" results when typing quickly due to cancelled requests

[DanTup]

I'm trying to move my extension to using isIncomplete=true on Completion results to avoid preloading thousands of items in the first request. However, when I do this, the completion feels sluggish/doesn't update and I suspect it's due to how cancellations are handled.

I made a small completion provider that takes 40ms to return, and a test that types one character every 60ms (this means all requests complete without any cancellation). I include the offset of the request in the results to make it clear when updated results are shown. As expected, the completion list updates on every keystroke:

However, if I increase the completion provider to take 80ms to return (slightly longer than the delay between keystrokes), the completion list doesn't update at all until the typing stops:

My understanding is that when you type a new character, VS Code cancels the previous (in-flight) request and sends a new one. This makes sense. However, if the server returns the results anyway (perhaps it had already computed them), I think it would be a much better experience if VS Code still used those results while waiting for the next one. Otherwise, using isIncomplete=true results in completion feeling sluggish when typing slightly faster than the server is responding (server response times may increase slightly if lots of requests are being sent/cancelled, as there could be synchronous work that means they don't immediately handle the cancellation).

[DanTup]

Here is the code I used for testing. It can be pasted into src/test/suite/extension.test.ts in a project created with yo code:

import * as assert from 'assert';
import * as vs from "vscode";

suite('Extension Test Suite', () => {

	test('Sample test', async function () {
		this.timeout(100000000000);

		registerCompletionProvider();

		const doc = await vs.workspace.openTextDocument({ language: 'plaintext', content: '' });
		const editor = await vs.window.showTextDocument(doc);

		editor.selection = new vs.Selection(new vs.Position(0, 0), new vs.Position(0, 0));
		await delay(5000);
		await vs.commands.executeCommand('editor.action.triggerSuggest');
		await delay(1000);
		await typeSlowly('aaaaaaaaaaaaaaaaaaaa');


		await delay(600000);
	});

	async function typeSlowly(text: string) {
		for (const c of text.split('')) {
			await delay(60);
			await vs.commands.executeCommand('default:type', { text: c });
		}
	}

	function delay(milliseconds: number): Promise<void> {
		return new Promise((resolve) => setTimeout(resolve, milliseconds));
	}

	function registerCompletionProvider() {
		vs.languages.registerCompletionItemProvider({ language: 'plaintext' }, {
			provideCompletionItems: async (document: vs.TextDocument, position: vs.Position, token: vs.CancellationToken, context: vs.CompletionContext): Promise<vs.CompletionList> => {
				console.log(`Request for completions at ${position.character}`);
				await delay(80); // change this between 40 and 80ms
				const res = new vs.CompletionList(
					[
						new vs.CompletionItem(`aaaaaaaaaaaaaaaaaaaa(${position.character})`),
					],
					true,
				);
				return res;
			}
		});
	}
});

[DanTup]

Some other things that might be contributing to this feeling slower:

• The completion dropdown usually moves along on each update - if the second one also moved on each keypress (before waiting for the results), it wouldn't look so different. Although, I wonder if the moving is actually the best behaviour - it seems odd that it keeps getting further and further offset from where it will actually insert the displayed value
• There's no highlighting of the matched characters after a keystroke until the update arrives - highlighting in the existing results list prior to the update arriving could also make it less obvious something is taking longer