From ca683dd10c539ec1feda10d0d73911cb39c3fc62 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 08:18:45 -0400 Subject: [PATCH 1/6] Blazor Server reconnection coverage --- aspnetcore/blazor/fundamentals/signalr.md | 25 +++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index f2995a4d8ac7..982fd44a186c 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1127,6 +1127,31 @@ Blazor Server: **In the preceding example, the `{BLAZOR SCRIPT}` placeholder is the Blazor script path and file name.** For the location of the script and the path to use, see . +:::moniker range=">= aspnetcore-9.0" + +When the user navigates back to an app with a disconnected circuit, reconnection is attempted immediately rather than waiting for the duration of the next reconnect interval. This improves the user experience when navigating to an app in a browser tab that has gone to sleep. + +When a reconnection attempt reaches the server but the server has already released the circuit, a page refresh occurs automatically. This prevents the user from having to manually refresh the page if it's likely going to result in a successful reconnection. + +Reconnect timing uses a computed backoff strategy. The first several reconnection attempts occur in rapid succession without a retry interval before computed delays are introduced between attempts. The default logic for computing the retry interval is an implementation detail subject to change without notice, but you can find the default logic that the Blazor framework uses [in the `computeDefaultRetryInterval` function (reference source)](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20computeDefaultRetryInterval&type=code). + +[!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)] + +Customize the retry interval behavior by specifying a function to compute the retry interval. In the following exponential backoff example, the number of previous reconnection attempts is multiplied by 1,000 ms to calculate the retry interval. When the count of previous attempts to reconnect (`previousAttempts`) is greater than the maximum retry limit (`maxRetries`), `null` is assigned to the retry interval (`retryIntervalMilliseconds`) to cease further reconnection attempts: + +```javascript +Blazor.start({ + circuit: { + reconnectionOptions: { + retryIntervalMilliseconds: (previousAttempts, maxRetries) => + previousAttempts >= maxRetries ? null : previousAttempts * 1000 + }, + }, +}); +``` + +:::moniker-end + For more information on Blazor startup, see . :::moniker range=">= aspnetcore-6.0" From 2ff46cf292623e25b39c2440c2a7d004f5b0d1b8 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 19:45:24 -0400 Subject: [PATCH 2/6] Update aspnetcore/blazor/fundamentals/signalr.md Co-authored-by: Mackinnon Buck --- aspnetcore/blazor/fundamentals/signalr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 982fd44a186c..9771ff094031 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1133,7 +1133,7 @@ When the user navigates back to an app with a disconnected circuit, reconnection When a reconnection attempt reaches the server but the server has already released the circuit, a page refresh occurs automatically. This prevents the user from having to manually refresh the page if it's likely going to result in a successful reconnection. -Reconnect timing uses a computed backoff strategy. The first several reconnection attempts occur in rapid succession without a retry interval before computed delays are introduced between attempts. The default logic for computing the retry interval is an implementation detail subject to change without notice, but you can find the default logic that the Blazor framework uses [in the `computeDefaultRetryInterval` function (reference source)](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20computeDefaultRetryInterval&type=code). +The default reconnect timing uses a computed backoff strategy. The first several reconnection attempts occur in rapid succession before computed delays are introduced between attempts. The default logic for computing the retry interval is an implementation detail subject to change without notice, but you can find the default logic that the Blazor framework uses [in the `computeDefaultRetryInterval` function (reference source)](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20computeDefaultRetryInterval&type=code). [!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)] From cf518516afc59b72378286d11221c3567ce7c680 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 19:53:10 -0400 Subject: [PATCH 3/6] Updates --- aspnetcore/blazor/fundamentals/signalr.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 9771ff094031..485c4ac2f8a6 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1129,9 +1129,7 @@ Blazor Server: :::moniker range=">= aspnetcore-9.0" -When the user navigates back to an app with a disconnected circuit, reconnection is attempted immediately rather than waiting for the duration of the next reconnect interval. This improves the user experience when navigating to an app in a browser tab that has gone to sleep. - -When a reconnection attempt reaches the server but the server has already released the circuit, a page refresh occurs automatically. This prevents the user from having to manually refresh the page if it's likely going to result in a successful reconnection. +When the user navigates back to an app with a disconnected circuit, reconnection is attempted immediately rather than waiting for the duration of the next reconnect interval to resume the connection as quickly as possible for the user. The default reconnect timing uses a computed backoff strategy. The first several reconnection attempts occur in rapid succession before computed delays are introduced between attempts. The default logic for computing the retry interval is an implementation detail subject to change without notice, but you can find the default logic that the Blazor framework uses [in the `computeDefaultRetryInterval` function (reference source)](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20computeDefaultRetryInterval&type=code). @@ -1150,6 +1148,18 @@ Blazor.start({ }); ``` +Specify the exact milliseconds of each interval for precise retry interval control. After the last specified retry interval, retries stop because the function returns `undefined`: + +```javascript +Blazor.start({ + circuit: { + reconnectionOptions: { + retryIntervalMilliseconds: Array.prototype.at.bind([0, 1000, 2000, 5000, 10000, 15000, 30000]), + }, + }, +}); +``` + :::moniker-end For more information on Blazor startup, see . From 7a60ec87eb653c4dc8d4d1e2ed2e7fa141c5da48 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 19:54:25 -0400 Subject: [PATCH 4/6] Updates --- aspnetcore/blazor/fundamentals/signalr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 485c4ac2f8a6..f739d3eaef13 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1129,7 +1129,7 @@ Blazor Server: :::moniker range=">= aspnetcore-9.0" -When the user navigates back to an app with a disconnected circuit, reconnection is attempted immediately rather than waiting for the duration of the next reconnect interval to resume the connection as quickly as possible for the user. +When the user navigates back to an app with a disconnected circuit, reconnection is attempted immediately rather than waiting for the duration of the next reconnect interval. This behavior seeks to resume the connection as quickly as possible for the user. The default reconnect timing uses a computed backoff strategy. The first several reconnection attempts occur in rapid succession before computed delays are introduced between attempts. The default logic for computing the retry interval is an implementation detail subject to change without notice, but you can find the default logic that the Blazor framework uses [in the `computeDefaultRetryInterval` function (reference source)](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20computeDefaultRetryInterval&type=code). From db3348029d56627cd7a30a48d8356b41edd7c029 Mon Sep 17 00:00:00 2001 From: Luke Latham <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 19:56:29 -0400 Subject: [PATCH 5/6] Update aspnetcore/blazor/fundamentals/signalr.md Co-authored-by: Mackinnon Buck --- aspnetcore/blazor/fundamentals/signalr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index f739d3eaef13..cd989e1b790c 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1148,7 +1148,7 @@ Blazor.start({ }); ``` -Specify the exact milliseconds of each interval for precise retry interval control. After the last specified retry interval, retries stop because the function returns `undefined`: +An alternative is to specify the exact sequence of retry intervals. After the last specified retry interval, retries stop because the `retryIntervalMilliseconds` function returns `undefined`: ```javascript Blazor.start({ From 491ec9b718c2073baca0de381245f67282cf2635 Mon Sep 17 00:00:00 2001 From: guardrex <1622880+guardrex@users.noreply.github.com> Date: Mon, 10 Jun 2024 20:01:07 -0400 Subject: [PATCH 6/6] One more: The code was a bit too wide for us! --- aspnetcore/blazor/fundamentals/signalr.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index cd989e1b790c..9e5c66d3627e 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -1154,7 +1154,8 @@ An alternative is to specify the exact sequence of retry intervals. After the la Blazor.start({ circuit: { reconnectionOptions: { - retryIntervalMilliseconds: Array.prototype.at.bind([0, 1000, 2000, 5000, 10000, 15000, 30000]), + retryIntervalMilliseconds: + Array.prototype.at.bind([0, 1000, 2000, 5000, 10000, 15000, 30000]), }, }, });