fix(clusters): Restart Cluster reports a failed cluster load instead of staying disabled

[dawsontoth]

Stacked on #1861 (claude/1339-replicated-set-configuration). Merge #1861 first, then retarget this PR to stage.

⊙ Problem

Restart Cluster fetched the cluster and built a client for each instance before entering any try. When that failed (a central manager 5xx or 403, a dropped connection, a malformed instance FQDN), the click handler rejected unhandled. The Restart button stayed disabled until the page remounted, the "Restarting" toast spun for its full 60s without an error, and the rejection reached the console as an unhandled one (#1853). #1861 fixed the same failure in the config editor's save.

❓ Your call: Is the stack worth it? The shared helper replaces client-building code that only exists on #1861's branch, so this PR has to wait for #1861. The alternative is to base it on stage, fix only the restart hook, and keep the duplicate copy. That is easy to undo: rebase onto stage and drop the useRollingConfigUpdate hunk.

💡 Solution

• One planner for both hooks. The new getClusterRestartTargets helper (src/hooks/getClusterRestartTargets.ts) fetches the cluster, checks Fabric Connect, keeps the RUNNING instances, builds one client each, and reverses the order. Restart Cluster and the config update used to build this list separately; both now call the helper. In useRollingConfigUpdate.tsx, planRollingConfigUpdate keeps only the replication FQDN it adds on top.
• Restart Cluster survives a failed load. In useRestartClusterClick.tsx, the load runs inside a try. If it fails, the restart toast ends with "Could not load the cluster's instances, so nothing was restarted." The pending state is cleared in a finally that covers every exit. This mirrors feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861.
• An empty cluster is no longer reported as "Cluster fully restarted!" The success branch now requires at least one instance, so an empty cluster gets the "No instances were found" error. feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861 made the same fix in the config update.

Also fixed (found by the pre-push review; both bugs are older than this branch):

• Cancel during an instance's availability check. All three Cancel-toast loops checked the Cancel flag only at the top of each iteration. A Cancel clicked while the probe was in flight was ignored, and the restart, config write or license install still went out. Each loop now checks the flag again after the probe, before its first request that changes the instance: restart, config update, and apply licenses (useApplyLicensesClick.tsx).
• Misleading "none were RUNNING" message. When every RUNNING instance failed to restart, the toast said "No instances were in a RUNNING state". The message is now keyed on there being no RUNNING target (restart, config update), so that case now reads "Only 0 RUNNING instances were restarted of N".

❓ Your call: A failed load no longer reaches RUM. Before this change it was reported as an unhandled rejection; now the toast handles it and nothing is logged, which is how #1861 treats the config save. To keep the signal, add a console.error in the catch: the RUM SDK reports those with error.source: "console". That is a one-line change either way.

⚖️ Alternatives

• Copy feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861's catch into the restart hook without a shared helper. Rejected: the two hooks built identical target lists, including the reverse order, and two copies can drift apart.
• Clear the pending state in two places instead of one outer try/finally. That gives a smaller diff with less re-indentation, but it is easier to miss an exit path, and it would not match feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861. The links here use ?w=1, which hides the indentation noise.

✅ Verification

• Fails on base: run against the base hook, the load-failure tests in useRestartClusterClick.test.tsx fail with the reported bug: onRestartClick rejects with Error: 503 (the cluster fetch) or TypeError: Invalid URL (client construction). The four review-fix tests also fail before their fix: Cancel during the check for restart, config update (useRollingConfigUpdate.test.tsx) and licenses (useApplyLicensesClick.test.tsx, a new harness), plus the all-failed message for restart and config update. All of them pass with the fix.
• Helper unit tests (getClusterRestartTargets.test.ts) pin the RUNNING filter, the reverse order, the Fabric Connect flag, a missing instance list, and that a failed fetch rejects before any client is built.
• Mutation checks: reverting the zero-instance guard makes its test fail, and so does removing the finally that clears the pending state.
• Full suite (pre-commit hook, Node 24.21.0): 400 files, 3,714 passed, 11 skipped. tsc -b, oxlint and dprint check all exited 0.
• End-to-end route: not observable end-to-end without making central manager fail on demand. The tests drive the real hook through renderHook, with the real restart tracker, and assert that the cluster is never marked as restarting when the load fails. I did not verify in a browser.
• Cross-model review: two rounds. Codex graded round 1 CHANGES and round 2 LGTM, with its major finding resolved. I rejected gemini's two round-2 minors on the code: every loop already skips cancelled iterations through its outer guard, and useRollingConfigUpdate already has the empty-cluster success guard from feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861. The Harper adjudicator could not run because its Claude OAuth session had expired, and the Cursor leg could not run because the 1Password SSH agent refused to sign.
• gemini-code-assist feedback: took all three suggestions in 1bbbc43. The cancel checks added after the probe now break instead of continue, because the flag never resets and later iterations only re-checked it. The finally that releases each instance's restart marker still runs, and all of the cancel-during-check tests above pass. The branch also merges feat(config): fan cluster config saves out with replicated set_configuration on Harper 5.2+ #1861's matching change to its own loop-top guard (3581be6). These are refactors with unchanged behavior, so no further review round ran.

Closes #1853

🤖 Generated with Claude Code

_{🤖 Generated by Claude Code (Anthropic Claude); posted via @dawsontoth.}

Related PRs: #1861 overlaps (this PR's base; it reuses #1861's cluster-load catch and replaces its target planning with the shared helper), #1899 overlaps (reworks the same restart and config-update loops in useRestartClusterClick.tsx and useRollingConfigUpdate.tsx)
Complexity: medium

_{Review-Coverage: authored=claude; ran=codex,gemini; blocked=cursor-composer(no-receipt),domain(auth); declined=cursor-grok,cursor-kimi,cursor-muse; rounds=2; full=1 @ 1bbbc43}

_{Review-Attention: read ~6m (raised: degraded review) @ 1bbbc43}

[gemini-code-assist]

Code Review

This pull request introduces a new helper function getClusterRestartTargets to centralize the logic of retrieving and preparing running instances for cluster restarts, which is then integrated into useRestartClusterClick and useRollingConfigUpdate to reduce duplication. It also adds cancellation checks after verifying instance responsiveness across several hooks. The review feedback suggests optimizing these cancellation checks by replacing continue with break inside the loops, as the canceled state is persistent and breaking early avoids unnecessary iterations.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	74.05%	12304 / 16614
🔵	Statements	74.12%	13100 / 17673
🔵	Functions	68.66%	3263 / 4752
🔵	Branches	69.55%	9660 / 13888

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/hooks/getClusterRestartTargets.ts	100%	100%	100%	100%
src/hooks/useApplyLicensesClick.tsx	81.08%	47.61%	50%	80.55%	87-94, 114, 125-140
src/hooks/useRestartClusterClick.tsx	90.19%	88.88%	42.85%	90%	32, 68, 146, 157, 179
src/hooks/useRollingConfigUpdate.tsx	93.65%	97.43%	60%	93.54%	103, 193, 204, 227

Generated in workflow #2286 for commit 3afc3a9 by the Vitest Coverage Report Action