cmoriarty/braid
1
0
Fork 0
Code Issues 15 Pull requests Projects Releases Packages 1 Wiki Activity Actions

The status light has one state and says nothing about the backend #3

New issue
Closed
opened 2026-09-13 07:43:07 -04:00 by cmoriarty · 1 comment
cmoriarty commented 2026-09-13 07:43:07 -04:00
Owner
Copy link

Reported from the running system. The live dot is the right idea and carries almost
no information: it is on, or it is not.

What it should carry

  • More than one status. At least ready, running, down — and the states the
    system already distinguishes internally and hides here: the upstream being unreachable
    is not the same as the stream being disconnected, and neither is the same as idle.
    Colour should carry the distinction, not just presence.
  • Which backend is connected, named: vLLM · qwen3.8-27b. Braid is intended to be
    extensible to other backends, and the moment there is more than one, "which model am I
    actually talking to" becomes the first question anybody asks of a run — especially when
    a run behaves differently from yesterday's.

Why this is not cosmetic

/healthz already distinguishes the cases (upstream stale, no server for a running step,
the liveness survey's own age) and GET /api/slots already reports the upstream endpoint
and its vLLM metrics. The information exists and is thrown away at the last inch. A
single green dot for "something is fine" is the shape of status display that teaches
people to stop looking at it.

Acceptance

  • The light distinguishes at least ready / running / down, by colour, and says which is
    which to a screen reader.
  • The connected backend is named in the chrome, read from what the system already probes.
  • Adding a second backend later changes the string and nothing else.

Written from watching the running system. Source: docs/issues/03-the-status-light-should-say-what-is-connected.md.

**Reported from the running system.** The live dot is the right idea and carries almost no information: it is on, or it is not. ## What it should carry - **More than one status.** At least `ready`, `running`, `down` — and the states the system already distinguishes internally and hides here: the upstream being unreachable is not the same as the stream being disconnected, and neither is the same as idle. Colour should carry the distinction, not just presence. - **Which backend is connected**, named: `vLLM · qwen3.8-27b`. Braid is intended to be extensible to other backends, and the moment there is more than one, "which model am I actually talking to" becomes the first question anybody asks of a run — especially when a run behaves differently from yesterday's. ## Why this is not cosmetic `/healthz` already distinguishes the cases (upstream stale, no server for a running step, the liveness survey's own age) and `GET /api/slots` already reports the upstream endpoint and its vLLM metrics. The information exists and is thrown away at the last inch. A single green dot for "something is fine" is the shape of status display that teaches people to stop looking at it. ## Acceptance - The light distinguishes at least ready / running / down, by colour, and says which is which to a screen reader. - The connected backend is named in the chrome, read from what the system already probes. - Adding a second backend later changes the string and nothing else. --- *Written from watching the running system. Source: `docs/issues/03-the-status-light-should-say-what-is-connected.md`.*
cmoriarty commented 2026-09-13 12:34:48 -04:00
Author
Owner
Copy link

Done and verified against the live system.

  • More than one status, by colour and word. GET /api/status reduces healthz to ready / running / starting / degraded / down. The page adds what only it can see: connecting (no answer yet), offline (status unanswered 12s), reconnecting (live updates silent 25s). From the slot strip's own numbers: ◐ ready when only outside traffic is on the server, and backend full in words when a run started now would wait (with "its memory is full" when that happens beside free slots).
  • Screen readers hear the state and the backend via a live region; the reason with its numbers is the light's description.
  • The backend is named — vLLM · qwen3.8-27b, from one backend_identity() in osfd shared by /api/status and /api/slots. After review, it lives on the rail's slot strip and the Inference screen, and in the light's description; the header carries only the light, by request. A second backend changes that one function's output and nothing else.
  • Verified in Chromium: cold load says connecting; offline 10s after status was blocked and back 2s after; reconnecting at 25.2s on a hung stream; no false state over 45s idle; backend full fits the header without wrapping from 1024 to 1440px.

Commits: 189908d, e398d36 (pushed), e570721 (local main, not yet pushed).

Done and verified against the live system. - **More than one status, by colour and word.** `GET /api/status` reduces healthz to `ready` / `running` / `starting` / `degraded` / `down`. The page adds what only it can see: `connecting` (no answer yet), `offline` (status unanswered 12s), `reconnecting` (live updates silent 25s). From the slot strip's own numbers: `◐ ready` when only outside traffic is on the server, and `backend full` in words when a run started now would wait (with "its memory is full" when that happens beside free slots). - **Screen readers** hear the state and the backend via a live region; the reason with its numbers is the light's description. - **The backend is named** — `vLLM · qwen3.8-27b`, from one `backend_identity()` in osfd shared by `/api/status` and `/api/slots`. After review, it lives on the rail's slot strip and the Inference screen, and in the light's description; the header carries only the light, by request. A second backend changes that one function's output and nothing else. - Verified in Chromium: cold load says `connecting`; `offline` 10s after status was blocked and back 2s after; `reconnecting` at 25.2s on a hung stream; no false state over 45s idle; `backend full` fits the header without wrapping from 1024 to 1440px. Commits: 189908d, e398d36 (pushed), e570721 (local main, not yet pushed).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
archive/prefect-kestra-experiments
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cmoriarty/braid#3
No description provided.