apache / apache/texera

Surface failed/unhealthy computing units instead of showing "Connecting" indefinitely

Open
#7,669 0 comments 0 reactions 1 assignee Claimed by @eugenegujing View on GitHub
Dominant language
Scala
Stars
314
Forks
187
Avg merge
1d 21h
Merged PRs (30d)
214

Description

### Feature Summary

>

Image

>
> *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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.