PR 19764 review

rancher/dashboard PR 19764 (codyrancher) at head ad9b8b26, reviewed 2026-11-03. It fixes your issue 19761: outside Cluster Explorer, every side nav group collapsed whenever the nav was rebuilt.

Preview: rancherpr19764r.mf-created-dashboard.ui.rancher.space, built from ad9b8b26, backend mf Rancher. Baselines: the shared dashboard-master and harvester-main previews.

Verdict: approve

No blockers. The bug is fixed everywhere I tried it, including your Harvester repro, and nothing regressed in Explorer.
The fix carries each group's state from the tree being replaced. Only SideNav.vue changes, by a few lines.
3 of the 4 new tests fail with master's SideNav.vue put back. The 4th (saved state for a group not on screen) passes on both, as a guard.
One optional nit, in a pending review for you to edit or submit. Nothing is published.
One decision for you, not for Cody: the milestone (below).

Test it yourself

Log in as the local admin on the Rancher previews (RANCHER_PASSWORD) and on the Harvester ones (HARVESTER_PASSWORD). Harvester goes through the mf tunnels, so they need to be up from the Mac.

Fleet: open Bundles, leave Resources expanded, and switch the header workspace to fleet-local. Master collapses it in under a second.
Harvester: expand Backup and Snapshots, click Virtual Machine Backups, expand Advanced, and pick default in the namespace filter.

The namespace and workspace choices save to the shared admin's prefs when you do this by hand. My runs answered those writes locally, so nothing changed.

Live results

Case	master / main	PR 19764
Fleet: Resources open, switch workspace to fleet-local (the PR's walk)	Collapses 400-800ms later	Stays open
Harvester standalone: Backup and Snapshots + Advanced open, namespace filter to `default` (the issue's repro)	Every group collapses, active item hidden	Both stay open, active item visible
Cluster Management: Advanced open, `getGroups()`	Collapses	Stays open
Explorer: nested `More Resources > API` opened by the current page, `getGroups()` twice	Nested group collapses	Stays open
Fleet → Cluster Management → Fleet, on App Bundles	Resources closed when sampled about 4s after coming back	Resources open
Explorer: namespace filter change, then reload	Keeps groups	Same
Explorer: `local` → `created-dashboard-2` → `local`, each with different groups saved	Each cluster keeps its own	Same, nothing crosses over in localStorage
Explorer → Fleet → Cluster Management → Explorer	Explorer state intact	Same, no Fleet names in the saved state
Collapse all, then rebuild, reload (Explorer)	Stays collapsed; reload opens only the current page's group	Same
Collapse all, then rebuild + workspace switch (Fleet)	Stays collapsed	Same
Starred: starts expanded with nothing saved, stays collapsed once collapsed and rebuilt	Works	Same
Cluster Management Advanced open → Harvester cluster (both have `advanced`)	Harvester Advanced closed	Same: the cluster change clears the tree first

Fleet nav on master after the workspace switch: Resources collapsed — Fleet, master, after the workspace switch

Fleet nav on the PR after the workspace switch: Resources still expanded — Fleet, PR, after the workspace switch

Harvester main after the namespace filter change: every group collapsed — Harvester main, after the namespace filter change

Harvester with the PR SideNav after the namespace filter change: both groups expanded — Harvester + PR's SideNav, after the namespace filter change

Findings

The new rule has no comment in the code

shell/components/SideNav.vue:322

Nit, optional

The PR drops the comment above stampNavState. Why the on-screen tree now beats localStorage is explained only in the PR description. A one-line why would stop someone simplifying it back to load(), though the new tests would catch that too.

In the pending review

nit: this comment was the only explanation of the state flow here, and the new rule (the tree on screen beats localStorage, because nothing is saved outside Explorer) now lives only in the PR description. Could one line of that come back here, so nobody simplifies this back to load()?

Should this stay on 2.17?

Milestone v2.17.0, Branch Milestone check red

Your call

The regression came from PR 18195, which is on v2.16.0. Master still maps to v2.16.0 and there is no release-2.16 branch yet, so the red gate keeps this PR out of 2.16. If it stays on 2.17, 2.16.0 ships with the collapse in Fleet, Cluster Management and every other non-Explorer product, unless it is backported (the issue already has status/backport-candidate).

2.17 follows your default for new issues, so I left it alone and did not raise it with Cody. Moving it to v2.16.0 would turn the gate green.

Checked

Unit tests: SideNav, nav and useClusterLocalStorage suites pass (19 suites, 534 tests). eslint is clean on both changed files.
Test isolation: the new describe leaves the product getters set to Fleet, but the top-level beforeEach resets them, so nothing leaks.
"None share names today": holds for the products sharing the _ cluster. Across mf's active products only advanced repeats (Cluster Management, Harvester), and that switch clears the tree, so nothing carries over.
Failing CI: Branch Milestone is the expected 2.17 gate (other 2.17 PRs fail it too). e2e-test (admin, @virtualizationMgmt, @fleet) fails on the Harvester "missing repo message" test, which also fails on today's two latest master runs. I did not look for its cause. Its third attempt was still running when I finished.
Master baseline: 8 days old, but SideNav.vue, Group.vue and the storage composable have not changed on master in that time.

Not checked

The Harvester preview is Harvester main with only this PR's SideNav.vue hunks patched into shell 3.0.14, not a real shell release.
Admin only: I did not run Standard User, because the change has no permission logic.
Non-Explorer state still doesn't survive a reload. The PR says that is deliberate.