Problem
When a .test URL is hit and the requested service is not yet running, the
loading page shows a spinner and redirects when that specific service reaches
up. With service dependency ordering (#16), the requested service may sit
queued for a while as its dependencies start in topological order. The user
sees an opaque spinner with no signal that progress is being made.
Proposal
The loading page should subscribe to the requested service's full dependency
closure and render progress as each dependency transitions through starting
and up. The user sees concrete forward motion: "vite: up", "queue: up",
"rails: starting", instead of a single indefinite spinner.
Open questions
- Visualization: progress bar (N of M up), per-service status list, or both?
- What does "progress" mean when several dependencies start in parallel?
- How is an upstream
crashed rendered — the same as the current "app
crashed" page, or inline on the loading page identifying which dep failed?
Scope
Depends on #16 landing first (the dep closure has to exist before the loading
page can subscribe to it).
Out of scope: changing the per-service status broadcasts themselves — those
already exist and are sufficient for this UI.
Problem
When a
.testURL is hit and the requested service is not yet running, theloading page shows a spinner and redirects when that specific service reaches
up. With service dependency ordering (#16), the requested service may sitqueued for a while as its dependencies start in topological order. The user
sees an opaque spinner with no signal that progress is being made.
Proposal
The loading page should subscribe to the requested service's full dependency
closure and render progress as each dependency transitions through
startingand
up. The user sees concrete forward motion: "vite: up", "queue: up","rails: starting", instead of a single indefinite spinner.
Open questions
crashedrendered — the same as the current "appcrashed" page, or inline on the loading page identifying which dep failed?
Scope
Depends on #16 landing first (the dep closure has to exist before the loading
page can subscribe to it).
Out of scope: changing the per-service status broadcasts themselves — those
already exist and are sufficient for this UI.