fix(frontend): fall back to a running unit on workflow load

[eugenegujing]

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

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• No candidates found from git blame history.

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. A release/* label nominates a backport target; the branch's release manager approving this PR is what sends the fix there. The required Backport Approvals check stays red until every label below is approved, so each manager either approves or removes their own label — which is why the labels left on a merged PR are exactly the branches it reached.

Release branch	Analysis
✅ release/v1.3	Change detected on this branch — label added; this fix is queued to backport here. @mengw15 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. @xuang7 decides: approving sends the fix here, removing this label declines it. The merge waits on one or the other. Review requested.

Auto-label run.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.59%. Comparing base (40b507d) to head (42484fa).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8935      +/-   ##
============================================
- Coverage     92.60%   92.59%   -0.01%     
  Complexity     5043     5043              
============================================
  Files          1252     1252              
  Lines         53587    53592       +5     
  Branches       6673     6675       +2     
============================================
+ Hits          49622    49624       +2     
  Misses         2317     2317              
- Partials       1648     1651       +3     

Flag	Coverage Δ		*Carryforward flag
access-control-service	77.38% <ø> (ø)		Carriedforward from 40b507d
agent-service	99.16% <ø> (ø)		Carriedforward from 40b507d
amber	88.09% <ø> (ø)		Carriedforward from 40b507d
computing-unit-managing-service	60.48% <ø> (ø)		Carriedforward from 40b507d
config-service	87.37% <ø> (ø)		Carriedforward from 40b507d
file-service	81.53% <ø> (ø)		Carriedforward from 40b507d
frontend	96.58% <100.00%> (-0.02%)	⬇️
notebook-migration-service	83.73% <ø> (ø)		Carriedforward from 40b507d
pyamber	98.52% <ø> (ø)		Carriedforward from 40b507d
workflow-compiling-service	74.09% <ø> (ø)		Carriedforward from 40b507d

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.