[browser] Allow download retry+throttling in unified code with blazor - #88910
Conversation
maraf
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
Does this fix the issue seen in #88505 (comment) ? |
Yes, it does |
Would it be possible to add some test to check that? |
That is the case with |
…rSdk # Conflicts: # eng/testing/scenarios/BuildWasmAppsJobsList.txt # src/mono/wasm/testassets/WasmBasicTestApp/wwwroot/main.js
…smDownloadRetryForSdk
|
Failures are unrelated |
| testOutput("Throw error instead of downloading resource"); | ||
| const error = new Error("Simulating a failed fetch"); | ||
| error.silent = true; | ||
| throw error; |
There was a problem hiding this comment.
Does this get surfaced to the user at all? What behavior does blazor have when we fail to load an assembly at all?
There was a problem hiding this comment.
Before this PR, the Blazor aborts on first download failure. Their original approach was to let the user override loadBootResource do retries by themself. After discussion with @pavelsavara we agreed that turn-on our built-in retry support.
There was a problem hiding this comment.
I meant, is this surfaced when even a 3rd retry fails?
| [Theory] | ||
| [InlineData(false)] | ||
| [InlineData(true)] | ||
| public async Task DownloadProgressFinishes(bool failAssemblyDownload) |
There was a problem hiding this comment.
Maybe rename to indicate that this is testing retries.
There was a problem hiding this comment.
(intended) Retry happens only when failAssemblyDownload=true
There was a problem hiding this comment.
Yeah, and that's what we are testing here :)
There was a problem hiding this comment.
We are testing "download progress" counter, one case is with retry and one is without
ghost
locked as resolved and limited conversation to collaborators
4 participants
onDownloadResourceProgress)DotnetHostBuilder(unrelated, used in blazor)