Surface failed/unhealthy computing units instead of showing "Connecting" indefinitely
- Dominant language
- Scala
- Stars
- 314
- Forks
- 187
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 214
Description
### Feature Summary
>
>
> *Caption: the computing unit dropdown. `CU 2` is healthy (green dot, selected). `CU 1` sits at a gold dot with the literal `(Connecting)` label — that is the only thing the UI ever says about it, whether it is two seconds into startup or has been dead for an hour. Hovering it reads "Computing unit is starting up".*
When a computing unit (CU) becomes unhealthy — the pod crashes, gets OOM-killed, is evicted, fails to pull its image, or the local CU process dies — the UI gives the user no indication that anything is wrong. The run button just says **"Connecting"** with a spinner, forever, and the dropdown entry shows **"(Connecting)"** with a tooltip that reads **"Computing unit is starting up"**. There is no timeout, no error state, and no way for the user to tell "still booting" apart from "dead and never coming back".
### Proposed Solution or Design
**1. Add terminal/unhealthy values to `ComputingUnitState`** (`Failed`, `Unknown`, `Terminating`) so a failure has somewhere to live. Requires the matching widening of the frontend DTO type, which is `status: "Running" | "Pending"` today.
**2. Map real pod state in `ComputingUnitHelpers` instead of collapsing it**, so pod phase `Failed`/`Unknown`, a deleted or evicted pod, and container-level states (`CrashLoopBackOff`, `ImagePullBackOff`, `OOMKilled`) stop reporting as `Pending`. Carry the reason as a `statusReason` string on the CU DTO so the UI can say *why*.
Contributor guide
Assessment
This issue has not been assessed yet.