Repository navigation
Recover stale relay connections and explain outage layers - #1638
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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
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.
A selected remote target can remain recorded while its SSH forward resets every backend request. The browser then shows the same generic offline page used for a stopped local relay, and refreshing cannot repair the forward.
The relay now rebuilds a failed or exited SSH forward once for all tabs, verifies the replacement, and retries failed recovery with backoff. Its status reports whether the selected target is healthy, reconnecting, or unavailable; a same-origin reconnect action supports a manual retry. A connection lifecycle hook combines that status with the backend heartbeat so the recovery screen distinguishes local relay loss, a remote target outage, and a local backend outage. Fleet discovery remains outside the heartbeat. The screen shows the selected Machine and AliceProject, offers location switching only while the relay is reachable, and preserves the current page during recovery.
The interaction uses the existing full-screen recovery surface and location chooser. It keeps focus on the alert dialog, announces changing status, stacks controls on narrow screens, and respects the existing reduced-motion spinner behavior. Copy is updated in all four UI locales.
Validation: root and UI typechecks; complete
pnpm test(7334 passed, 5 skipped); targeted relay, auth, lifecycle-hook, and chooser specs (25 passed); real browser at port 5177 with independent backend and relay failure injection, followed by recovery to Settings. The reported port-5175 incident was reproduced as relay status 200, backend proxy 502ECONNRESET, remote Runtime 200 over SSH; rebuilding its selected forward restored backend HTTP 200 without restarting the remote Runtime.