[Blazor] each navigation to external logs 2 errors a minute later #53271
Conversation
…es asynchronously
ghost
added
the
| } | ||
| // If we are navigating to an external URI, defer setting the URL so that we can | ||
| // complete the current navigation operation if the request comes from .NET. | ||
| setTimeout(() => { |
There was a problem hiding this comment.
Is one downside to this approach (compared to the other one you proposed) that we don't actually wait for the "end .NET->JS interop" message to be sent across the wire before tearing down the page? i.e., there's still a possibility that the bug appears, especially when the user has an unreliable connection?
There was a problem hiding this comment.
We don't want to swallow the exception when the circuit just gets disconnected, do we?
There was a problem hiding this comment.
That's my reasoning for it. It's better to support the call finishing than to catch the exception on the server at the risk of catching exceptions that we don't want to catch. Specially since the outcome of navigation can't be observed by the user.
There was a problem hiding this comment.
Turns out that I still found cases where this can happen, even with the JS bits. So I switched to catching on the server with a new strategy
The browser used matters here. Chrome/Edge complete the navigation, but firefox doesn't.
…al sources asynchronously" This reverts commit d5cc18e.
|
/backport to release/8.0 |
|
Started backporting to release/8.0: https://github.com/dotnet/aspnetcore/actions/runs/7485830357 |
…nute later (#53297) Backport of #53271 to release/8.0 /cc @javiercn # [Blazor] each navigation to external logs 2 errors a minute later Capture an exception and log a message when navigation fails because the session has ended. ## Description - The user clicks the link to the target URL. - That link is intercepted in the JavaScript. - .NET is called to determine if navigation to the URL needs to be prevented. - It is determined that there is no need to prevent navigation and "navigateTo" is called via JS interop in NavigationManager.ts. - The URL is determined to be external by "navigateTo" and the location is set to the new URL. - The unload event in the browser is automatically triggered, which in turn triggers the call to _disconnect. - As a result, the promise to "navigateTo" never completes (the page gets unloaded before that) and the associated task in .NET ends up getting cancelled with a timeout. Fixes #45267 ## Customer Impact Customers see a large number of errors in their logs when their sites contain links to external sites, which in turn can trigger alerts in their incident monitoring systems. ## Regression? - [ ] Yes - [X] No ## Risk - [ ] High - [ ] Medium - [X] Low The scenario in which the issue happens is well defined and the fix is simple. ## Verification - [X] Manual (required) - [ ] Automated  ## Packaging changes reviewed? - [ ] Yes - [ ] No - [X] N/A ---- ## When servicing release/2.1 - [ ] Make necessary changes in eng/PatchConfig.props --------- Co-authored-by: jacalvar <[email protected]>
Scenario
This happens on navigations that are not part of Blazor Server, like a navigation to a Razor Page, or similar, but not to navigations to other origins.
Explanation
Fix
There were two possible fixes:
location.urlvia setTimeout. This allows the call to "navigateTo" to complete (and we log a message on the server to reflect that).TaskCancelledExceptionon the server and "swallow" the exception when !JSRuntime.IsInitialized.