eugenegujing opened a new pull request, #8935:
URL: https://github.com/apache/texera/pull/8935
### What changes were proposed in this PR?
**Root cause.** When a workflow opens,
`ComputingUnitSelectionComponent.selectFromLastExecution` selects the unit the
workflow last ran on without checking that the unit is still listed.
`/api/executions/{wid}/latest` also returns terminated units, so
`ComputingUnitStatusService.selectComputingUnit` waits forever for a `cuid`
that never appears, and the workflow opens with no unit selected even while
another unit is Running. The "first Running unit" fallback only ran when the
lookup failed, and it read the unit list synchronously, so it could select
nothing if the list had not loaded yet.
```
Before: open workflow -> last execution's unit was terminated -> wait for
it forever -> no unit selected
After: open workflow -> last execution's unit is not listed -> first
Running unit -> ready to run
```
Both screenshots: the workflow last ran on "Analytics Unit", which was then
terminated, and the workflow was reloaded. "My Computing Unit" is Running.
| Before | After |
| --- | --- |
| <img width="1512" height="805"
alt="restore-unit-2-reload-after-terminate-nothing-selected"
src="https://github.com/user-attachments/assets/8909822d-957b-465e-9adf-e2b4f7d20585";
/> | <img width="1456" height="829"
alt="restore-unit-5-after-fix-reload-dropdown-open"
src="https://github.com/user-attachments/assets/7531b109-a3e5-4b2d-a8c7-745997e9c559";
/> |
| No unit selected; the run button reads "Computing Unit". | "My Computing
Unit" is selected; the run button reads "Run". |
**Change.** Both branches of `selectFromLastExecution` now go through a new
`selectFromLoadedUnits`, which waits for the first non-empty unit list, as
`selectInitialUnit` already does for a remembered unit. It then selects the
last execution's unit if it is listed, else the first Running unit, else
nothing. The warehouse preselect is unchanged.
Not in scope:
- Whether a unit that is still listed but has turned Failed should be
restored. It is selected as before.
- The check uses the unit list the page already holds. In the workspace that
list is refreshed on events such as opening the dropdown, renaming or
terminating a unit, or a websocket status change, not on a timer, so a unit
terminated in another tab since the last refresh can still be selected.
### Any related issues, documentation, discussions?
Closes #8933
The last-execution path dates from #3400. The remembered-unit path, which
already checks the list, came with #8456.
### How was this PR tested?
New tests in
`frontend/src/app/workspace/component/power-button/computing-unit-selection.component.spec.ts`:
- falls back to a Running unit when the last execution's unit is no longer
listed
- selects nothing when the last execution's unit is gone and no unit is
Running
- still selects the last execution's unit when it is listed but not Running
- waits for the unit list before deciding from the latest execution
- decides from the latest execution only once, on the first loaded list
- still falls back to a Running unit when the list arrives after the failed
lookup
- drops a latest-execution decision when the list arrives after the workflow
changed
- drops a pending latest-execution decision once the component is destroyed
- falls back to a Running unit when the latest execution has no unit
- falls back to a Running unit when both the remembered and the last
execution's unit are gone
- picks the first Running unit in list order when several are Running
- does not fall back to a unit that is Pending, Terminating, Failed or
Unknown, one case per status
- only preselects the warehouse when the unit was already settled by a
remembered choice
Existing tests in the same `describe` that go through the latest-execution
path now pass their unit list to `bootWithMetaStream(units)`, since the choice
depends on the loaded list. Their expectations are unchanged. "prefers the
remembered unit for this workflow over the latest execution" now also puts the
latest execution's unit in the list; otherwise the new code would skip that
unit anyway, and the test would no longer show that the remembered unit wins.
```
cd frontend
NODE_OPTIONS="--no-experimental-webstorage" npx ng test --watch=false
--include
src/app/workspace/component/power-button/computing-unit-selection.component.spec.ts
# 211 passed
NODE_OPTIONS="--no-experimental-webstorage" npx ng test --watch=false
# 233 files, 6593 passed | 1 skipped
npx tsc --noEmit -p tsconfig.json # clean
npx eslint <changed files> # clean
npx prettier --check <changed files> # clean
```
The `NODE_OPTIONS` setting is only needed locally on Node 25, whose built-in
`localStorage` shadows jsdom's. CI runs Node 24 with `yarn --cwd frontend run
test:ci` and needs no flag.
Mutation check: each of these makes at least one new test fail: dropping the
list check, skipping a latest execution that has no unit, picking the last
Running unit instead of the first, picking the first unit regardless of status,
accepting any unit that is not Pending, dropping `untilDestroyed`, dropping the
workflow-change guard, dropping the non-empty-list wait, dropping `take(1)`,
reading the list synchronously in the no-history branch, ignoring `selectUnit =
false`, and preferring a Running unit over the last execution's unit.
Manual check in Chrome, 1512x861 viewport, against a build of this branch on
the local-dev stack with local computing units:
1. Create two local units and open a workflow with one Text Input operator.
2. Select unit A, select a warehouse, click Run, and wait for it to complete.
3. Terminate unit A from the unit dropdown's trash icon.
4. Reload the workflow. Before: no unit is selected and the run button reads
"Computing Unit". After: the Running unit is selected and the run button reads
"Run".
Also checked by hand: when the last execution's unit is still listed, that
unit is selected rather than the first Running one; a workflow that has never
run selects the first Running unit.
### Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (claude-fable-5-1, claude-opus-5-5).
Co-authored with Claude; the author reviewed the change before submission.
--
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]
