Incorrect handling of client-initiatied progress

[rchl]

Describe the bug
I believe that in this code:

pyright/packages/pyright-internal/src/languageServerBase.ts

Lines 462 to 467 in b12f134

	const progress = await this._getProgressReporter(
	params.workDoneToken,
	workDoneReporter,
	Localizer.CodeAction.findingReferences(),
	token
	);

the params.workDoneToken will always be undefined since the LSP library will remove the property in

https://github.com/microsoft/vscode-languageserver-node/blob/859a8ece3e14b130d531c6102b2d108196436bc4/server/src/common/progress.ts#L139-L147

called from:

https://github.com/microsoft/vscode-languageserver-node/blob/859a8ece3e14b130d531c6102b2d108196436bc4/server/src/common/server.ts#L1696-L1698

and pass it through the workDoneReporter argument in the pyright handler function.

So the server is never using the client-initiated progress token but always creating server-initiated one.

[erictraut]

Thanks for the bug report. Yeah, we never noticed this issue before because VS Code never provides a client-initiated progress handler in this case. The behavior of the LSP library is unfortunate because it makes it difficult for the server to differentiate between a client-initiated progress handler and a dummy (null) handler.

Here's a PR that attempts to work around this: #2546

[erictraut]

This is fixed in pyright 1.1.186, which I just published.