harvester-ui-extension PR 1196 (votdev, “fix: show resource counts for all side navigation items”, harvester issue 11984), re-reviewed on 2026-10-26 at head 08beeec. Round one was your Comment review on 85fb5e0 (2026-10-23). Since then the author rebased onto main (shell 3.0.14), squashed, answered three of the four threads and asked for review again. Nothing posted to GitHub yet.
Preview: https://harvesterpr1196r.mf-created-dashboard.ui.rancher.space/, built from 08beeec, backend Harvester v1.9.0-rc4 (10.115.252.118)
loadCluster loads the six lists the filtered counts need, in the background and watched. Landing anywhere, every item has its count within a second, except Cloud Configuration Templates, which the author left out on purpose (fine).Both previews talk to the Harvester at 10.115.252.118 (v1.9.0-rc4) through the tunnel. Log in as admin with the Harvester password. Use a new private window for each, so nothing is cached.
| Round one | Author's answer / change | Checked now |
|---|---|---|
Blocker (getters.ts:83): with “All Namespaces”, every namespaced item shows 0 on a fresh load (the namespace cache is still empty) | No reply on the thread, fixed in the code: countedNamespaces now returns Object.keys(rootGetters.namespaces()), as suggested | Done. Fresh Dashboard load: VMs 3, Volumes 9, Images 2, Secrets 83, all equal to their lists. Putting the old line back makes 3 of the 18 tests fail, including the “All Namespaces” one, so the fix is guarded |
Suggestion (:45): VM Schedules also counts snapshot-type schedules, which its list hides | “The VM Schedules count now excludes snapshot-type schedules too, like the list”: predicate + unit test | Done. With one backup and one snapshot schedule faked in the browser, the nav shows 1 and the list 1 row |
Suggestion (:119): items with a filter have no count until their list is loaded; count on the server, like Rancher | “We can't easily move to server-side filtered counts”: loadCluster now loads VM backups (and so VM snapshots), schedules, volume snapshots and storage classes in the background, without awaiting them. Cloud Configuration Templates left out, as that would load every ConfigMap | Done another way. Landing on Settings or Images, every one of these items has its count within 1 s; on main they stay blank. All loads are watched over the websocket, so the counts stay live. Agree on leaving the templates out (card 1) |
Suggestion (:41): Volumes and VM Networks only get a count when you land on the Dashboard | “loadCluster now also requests PVCs and VM Networks in the background” | Done. Landing on Settings: Volumes 9 = 9 rows, VM Networks 1 = 1 row. No list is requested twice when you do land on the Dashboard |
| Case | main (d6f6f7c) | PR (08beeec) |
|---|---|---|
| Fresh load of the Dashboard, “All Namespaces” | Hosts, Volumes, VM Networks, VM Snapshots, Volume Snapshots, Cloud Configuration Templates, Storage Classes, Secrets and Alertmanager blank; Images 3 vs 2 rows, Policies 13 vs 1 row | Every item has a count except Cloud Configuration Templates (by design). Every count the PR touches equals its list |
| Fresh load of Settings, and of Images | Same nine items blank | Only Cloud Configuration Templates blank; all others show within 1 s |
Only default selected, then every list opened | Nine items blank; Add-ons 0 vs 11 rows | Every count the PR touches equals its list |
| Fake data in the browser: 1 backup + 1 snapshot, 1 backup + 1 snapshot schedule, a volume snapshot of a PVC + one of a VM backup | (main shows the raw totals) | VM Schedules 1, VM Backups 1, VM Snapshots 1, Volume Snapshots 1 from the first second, each = 1 row |
| Websocket watches for the six background lists | None until a page loads them | All six watched (resource.start received) |
| Requests on a Dashboard landing | - | PVCs, network attachments and backups requested once each: no duplicates with the Dashboard's own loads |
The Backup and Snapshots group on the PR, Dashboard landing, with the fake backups, snapshots and schedules (browser only, nothing written to Harvester):
Agree with leaving it out: counting the templates from the store means loading every ConfigMap in the cluster. The author's comment in loadCluster says so, and the count appears as soon as the list is opened (1 = 1 row). Nothing to ask for.
Backups, schedules, volume snapshots and storage classes are new requests on every cluster load; PVCs and network attachments were already loaded by the Dashboard, the default landing page, and are not requested twice. All six stay watched. These lists are usually small, and the counts are worth it, so I wouldn't raise it.
Namespaces 43 vs 20 rows, Cluster Network Configuration 2 vs 3, Virtual Private Cloud 1 vs 3, Images with only default selected 2 vs 0 rows. All the same on main, so out of scope (as in round one). PCI Devices 181 matches its paging (“1 - 10 of 181”).
| Check | Result |
|---|---|
| CI on 08beeec | All green: lint, unit-tests, DCO |
| Unit tests | 18/18 store tests pass locally; with the old activeNamespaceCache line back, 3 fail (the blocker is covered) |
| Lint | yarn lint clean |
| Rebase | Rebased onto main d6f6f7c (shell 3.0.14) and squashed into one commit; the PR still only touches the three store files |
| Baseline | Shared main preview, built from d6f6f7c (the PR's merge base), same backend |
| Scope | Only what the PR adds or changes vs current main |
The PR preview runs with 5m CPU requests (the cluster's CPU requests are full; the repo script asks for 15m + 10m). Remove it once the PR merges:
kubectl -n harvester-preview delete deploy/harvester-pr1196 deploy/harvester-pkg-pr1196 svc/harvester-pr1196 svc/harvester-pkg-pr1196 ingress/harvester-pr1196 ingress/harvester-pkg-pr1196 cm/harvester-nginx-pr1196 cm/harvester-pkg-pr1196-nginx --ignore-not-found
The shared main preview stays.