-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature 'Navigate to' is currently unavailable due to an internal error #54464
Comments
Video_2021-06-29_163702.mp4A 100% repro for me on Roslyn solution. I think the solution must be fully loaded + wait for a while after typing. |
@AArnott do you know what can cause
|
StreamJsonRpc never does anything with URIs at all, unless it's as part of deserializing data in the message into your method arguments or return value. The error message you see there would have been copied from the original exception, which may have been thrown from user code (yours) rather than the library's. When StreamJsonRpc serializes exceptions, the error packet (and the RemoteInvocationException) should retain the original exception type and callstack if you look at that exception's properties. |
Is it possible for StreamJSONRpc to report this information as well in the stack produced? If we don't have a dump, it seems like it will be hard to get the underlying exception info. Thanks! |
It does, if you activate |
We already added support for that here: #53839 :-) Any other ideas? |
Is the entire callstack in the issue description representing client-side frames then? Or are some of them from the server? If none from the server, then I guess simulate an exception of that type in one of your RPC server methods to see whether/where the server frames show up on the client. |
So we haven't gotten anymore reports of this, so i'm goin gto close this out for now. |
@CyrusNajmabadi FYI, I just hit this in Preview 3.1 few days ago. |
@CyrusNajmabadi I just hit this again in Preview 4.
|
Oh. This isn't even navigate-to proper. This is LSP-search. @dibarbet @davidwengier does LSP do anything with URIs? I seem to recall there was some sort of conversion between paths/uris for the lsp protocol, but i'm not exactly sure how it works. It certainly seems like during the reporting of a nav-to entry that our LSP server is doing something here that is busted. |
This seems promising: private async Task ReportSymbolInformationAsync(INavigateToSearchResult result, CancellationToken cancellationToken)
{
var location = await ProtocolConversions.TextSpanToLocationAsync(
result.NavigableItem.Document, result.NavigableItem.SourceSpan, result.NavigableItem.IsStale, cancellationToken).ConfigureAwait(false);
Contract.ThrowIfNull(location); This ends up calling into helpers which make the URI. Note that it feels like this system assumes that all docs will have an absolute file path that can be convered to a URI. however, i'm not sure if this is true. @jasonmalinowski may know of cases (dynamic files?) where the filepath is not an absolute uri. |
I filed microsoft/vs-streamjsonrpc#720 to track improving 2 link exception propagation. |
II think you covered it in your PR - we convert between file paths and URIs (when we get a request we convert to file path, when we respond to a request, we convert to URI). Note that the stack traces here look to be coming from out of proc, but all the LSP file path conversion should be happening in-proc. |
This is due to how the rpc system is reporting errors that happen on the host unfortunately. |
Version Used:
main
StackTrace:
cc @CyrusNajmabadi
The text was updated successfully, but these errors were encountered: