dotnet
Failed requests to due inability to determine language for URI with query parameters
Looks like:
Likely our URI parsing is getting tripped up by the filepath showing twice, and seems to be trying to pull file extension from the part in the query parameters.
The issue is due to some recent changes in how we handle language specific requests. We are now attempting to figure out the language for a request before it gets enqueued. However, in certain cases we are failing to determine the language from the URI, both expected and unexpected.
- In the case of the file paths created by the git diff window (e.g. /git:blah), the URI is encoded with parameters. For non-file URIs we're returning the
AbsoluteUrias the document file path - https://github.com/dotnet/roslyn/blob/main/src/Features/LanguageServer/Protocol/Extensions/ProtocolConversions.cs#L174C30-L174C56. - Generally, if we fail to find the language from the file extension, we fallback to the languageId provided by the client. However now that we query for the language when the request gets queued, there can now be a race between didOpen (sets the languageId for the document after the request gets de-queued) and a followup request on that document (which attemps to look up the language before the didOpen sets the languageId).
We could push the language querying deeper into the queue, however that is relatively complex at moment. We allow different languages to have different handler types which makes deserialization complicated. Instead, we should expose and unify on the Roslyn LSP type definitions with our partners (Razor / XAML). This will allow us to deserialize without knowing the language (and allow us to push language determination deeper into the queue).