Come back to a match without watching the reconnect overlay - #77
Merged
Conversation
Switching away from the app during a match and back again left "Reconnecting..." on screen for about ten seconds, over a circuit the server was still holding. Nothing here was waiting: Blazor fires its first ten reconnect attempts with no delay between them at all, and a phone coming out of suspension has no network for that first moment — so all ten are spent and failed instantly, and every real reconnect starts from the five-second bucket that follows. The recorded schedule reads 0,0,0,0,0,0,0,0,0,0,5,4,3,2,1,0. Start Blazor by hand to replace that with one immediate attempt and then one a second, which is where a phone's radio actually comes back, and stretch the disconnected-circuit retention to ten minutes so stepping away for longer than the stock three still rejoins the match screen instead of rebuilding it. The retained-circuit count is capped in the same breath — reading is public, so every passer-by leaves a circuit behind for the length of that window. A machine Fly has scaled to zero still costs a reload; a restarted process has no circuits to rejoin. Said so in deployment.md rather than pretending otherwise. reconnect.spec.js reads the schedule Blazor applies rather than timing a rejoin, and fails against the stock one.
…tion-delay-bw2c5h # Conflicts: # CLAUDE.md
… circuits Four things the review found, all of them real: The start call lived in wwwroot/js, which made the app's whole interactivity depend on a second file arriving — and fail silently in exactly the way an empty blazor.web.js already does here. It is inline now, so it cannot go missing on its own. The retry window ran out after ~69 seconds against a ten-minute retention, so a tab that stayed awake gave up at minute one of a half-time break, and a long dead spot reloaded onto the browser's error page with nothing left retrying. It now covers the retention period. Capping DisconnectedCircuitMaxRetained at 20 bought memory nobody was short of by making eviction likelier, and the circuit evicted could as easily be the coach's. Back to the stock 100 — only unclean disconnects park a circuit at all, since a tab closed properly gives its own up on the spot. The spec's schedule assertion read Math.max of a possibly empty array, which is -Infinity and passes: had a reload wiped the recorded events, the one thing this test exists to measure would have been measured on nothing. Also dropped a dead maxRetries guard: the callback is documented as taking it, Blazor calls it with one argument, and the retry loop applies the cap itself.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switching away from the app during a match and back again left "Reconnecting..."
on screen for about ten seconds, over a circuit the server was still holding.
Nothing here was waiting: Blazor fires its first ten reconnect attempts with no
delay between them at all, and a phone coming out of suspension has no network
for that first moment — so all ten are spent and failed instantly, and every
real reconnect starts from the five-second bucket that follows. The recorded
schedule reads 0,0,0,0,0,0,0,0,0,0,5,4,3,2,1,0.
Start Blazor by hand to replace that with one immediate attempt and then one a
second, which is where a phone's radio actually comes back, and stretch the
disconnected-circuit retention to ten minutes so stepping away for longer than
the stock three still rejoins the match screen instead of rebuilding it. The
retained-circuit count is capped in the same breath — reading is public, so
every passer-by leaves a circuit behind for the length of that window.
A machine Fly has scaled to zero still costs a reload; a restarted process has
no circuits to rejoin. Said so in deployment.md rather than pretending otherwise.
reconnect.spec.js reads the schedule Blazor applies rather than timing a rejoin,
and fails against the stock one.