Bad `$/progress` token deserialize

[timxx]

As LSP spec progress said:

type ProgressToken = integer | string;

interface ProgressParams<T> {
	/**
	 * The progress token provided by the client or server.
	 */
	token: ProgressToken;

	/**
	 * The progress data.
	 */
	value: T;
}

the token can be integer or string, but in FormatterBase it decode as long, which may raise exception and flush log

StreamJsonRpc.RpcArgumentDeserializationException: 'Deserializing JSON-RPC argument with name "token" and position 0 to type "System.Int64" failed: Error converting value "backgroundIndexProgress" to type 'System.Int64'. Path 'params.token'.'

As clangd pass token as string

[AArnott]

Thanks for this report.

To clarify what would make the clangd interop work, what is the content of the string? Given we're deserializing the $/progress message within StreamJsonRpc, I believe that means the request ID came from StreamJsonRpc (since progress is reported to the client). But StreamJsonRpc only uses integer IDs in its requests. If clangd is providing progress updates with an ID that does not match the request, that's a bug in clangd, I would say.
Even if StreamJsonRpc could deserialize $/progress tokens that are strings, they wouldn't match the integer we used in the request and we'd just drop the update.

I wonder if clangd is transforming an integer into a string (3 becoming "3"). It shouldn't do that, because for the client to end up matching this, we'd have to experimentally try parsing the string as an integer and then if it happens to work, assume that it was meant to work and then try to match it against our dictionary of outbound requests.

Also, if clangd is transforming request IDs from integers to strings, how does StreamJsonRpc process the result message? Does clangd preserve the type of the ID for result messages, and only transform it to a string for $/progress updates?