One thing you can do is to add the error-ui that comes in the newer project templates, you can use it to show something to the user that there is a problem. We have a sample implementation of that in our demos that you can take a look at.
I am not sure if a setting or event will be available for this, however, judging by this MS issue: https://github.com/aspnet/AspNetCore/issues/11965.
Some improvements on reconnecting were made in the early preiews (https://github.com/aspnet/AspNetCore/issues/8003) although I am not sure they expose a configuration option.
There used to be an array of times where reconnection was retried in Preview 6, but the syntax changed and the most I could find is the following, which does not even have an Intellisense description, so I am not sure if it does exactly what you need it to do and whether/how it is respected/used:
endpoints.MapBlazorHub(opts => opts.WebSockets.CloseTimeout = new TimeSpan(1, 0, 0));
Perhaps in that configuration you can use the various SignalR options: https://docs.microsoft.com/en-us/aspnet/core/signalr/configuration?view=aspnetcore-3.0&tabs=dotnet. Perhaps something like this
opts.LongPolling.PollTimeout = new TimeSpan(1, 0, 0);
opts.WebSockets.CloseTimeout = new TimeSpan(1, 0, 0);
NOTE: leaving connections (and thus circuits) open for a long time opens up the server for a DoS attack and I am not sure it would be a good practice. The Blazor team has worked on implementing reconnections to the same circuit if it is still available on the server, and to the best of my knowledge it works, so an idle client has a good chance of not losing their work if they return in a reasonable time frame, you can read more about this here: https://docs.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-3.0. If keeping connections alive is important, perhaps you could issue JS Interop calls on intervals and look for exceptions if the client disconnected so you could hopefully salvage something (see here and here)
UI for Blazor