eugenegujing opened a new issue, #7669: URL: https://github.com/apache/texera/issues/7669
### Feature Summary ## Feature Summary > <img width="1305" height="867" alt="Image" src="https://github.com/user-attachments/assets/e47e3139-aecd-4dca-a477-0b0a16899ff0"; /> > > *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*. ### Affected Area Workflow UI -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
