server: evict saved namespace picks whose namespace was deleted

[hisco]

Problem

Radar persists the header namespace switcher's pick (no-auth local case) and applies it to every read. If the picked namespace is later deleted from the cluster, every endpoint silently returns empty — the UI looks like an empty cluster with no hint that a stale filter is the cause, and there is no recovery: the existing stale-pick recovery only triggers when RBAC filtering empties the pick, which never happens in no-auth mode (getUserNamespaces is a pass-through there). The pick re-seeds from settings on every request, so the state is permanent until the user manually finds and clears the namespace filter.

Fix

• Saved picks are pruned against the live namespace list when applied: deleted namespaces drop out; when none survive, the pick is fully evicted and reads fall back to unfiltered.
• Evict only on positive knowledge: when the namespace informer can't answer (namespace-scoped cache, restricted RBAC), picks pass through untouched — wrongly dropping a valid pick is worse than keeping a stale one.
• Explicit ?namespaces= query filters are unaffected; only the saved-pick fallback path prunes.
• The eviction persists to settings — in-memory-only eviction would be undone on the next request when the saved preference re-seeds from disk. Persistence is skipped under --namespace-scope, where the saved pick doubles as the cache-scope restore value.
• Pick mutations are serialized (nsPickMu), and the prune revalidates its snapshot under the lock before writing: a concurrent pick change or a kubeconfig context switch mid-request skips the write, so a slow read can't revert a fresh pick or persist old-context survivors under the new context's key.
• handleGetNamespaceScope reports through the same prune, so the scope endpoint and the read path can't disagree.

Testing

• 6 new tests: full eviction, partial trim, valid-pick-unaffected, informer-unavailable pass-through, and two race-guard regressions (pick changed mid-flight, context switch mid-flight). Full internal/server suite green including -race.
• Live verification on a kind cluster: a settings file pinning a nonexistent namespace previously made /api/namespaces return [] forever; with the fix the first request returns all 8 namespaces and rewrites settings with the stale pick removed (other settings preserved). A valid pick still filters correctly after restart.

https://claude.ai/code/session_019aHPAeh1q88KxMGgyDpESc

---

Note

Medium Risk
Touches shared namespace-filter state on every read and POST with new locking; incorrect pruning or persistence could change multi-user/no-auth visibility, though guards and conservative informer behavior limit blast radius.

Overview
Fixes a case where a persisted namespace switcher pick for a deleted namespace made every read look empty (especially in no-auth mode), with no self-healing because disk kept re-seeding the stale filter.

On the saved-pick fallback path, picks are now pruned against live cluster namespaces (pruneToExistingNamespaces / pruneDeletedNamespacePicks): partial trims drop gone names; full eviction clears the pick and reads fall back to unfiltered. Pruning is skipped when the informer cannot list namespaces (empty/nil existing), so valid picks are not dropped on uncertainty. Deleted-namespace eviction persists to settings.json for the no-auth single-user case; RBAC trims, empty-fallback clears, and disk seeding use commitPickMutation with persist=false.

commitPickMutation plus nsPickMu centralize read-path writes: compare-and-swap on the snapshotted pick and kube context, skip on concurrent POST or context switch, and avoid deadlocking handleSetActiveNamespace (release lock before the trailing GET). getActiveNamespaceForUserInContext pairs pick + context for one atomic snapshot. The same prune runs in handleGetNamespaceScope and parseNamespacesForUser so scope API and resource reads stay aligned.

Tests cover full/partial eviction, informer-unavailable pass-through, and race/context-switch guards.

^{Reviewed by Cursor Bugbot for commit 9a8dc6b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[nadaverell]

Review finding:

nsPickMu only protects the new deleted-namespace prune and the POST persist+set path. The existing read-path RBAC trim/clear still writes nsPreferences without the mutex or a “current pick still equals my snapshot” guard (handleGetNamespaceScope trims actives, and parseNamespacesForUser clears on empty fallback). A concurrent scope GET based on an old pick can still land after a user’s fresh POST and overwrite it with old survivors or clear it. This is the same lost-update class this PR is trying to close.

Fix: route all read-path pick mutations through the same locked compare-current-then-store helper, so stale read snapshots cannot mutate the live pick.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 338619c. Configure here.}

[cursor]

Empty namespace list skips eviction

Low Severity

pruneToExistingNamespaces treats any len(existing)==0 list as “informer unavailable” and leaves picks unchanged, but allNamespaceNames returns nil when the informer cannot answer and a non-nil empty slice when listing succeeds with zero namespaces. A cluster with no namespaces therefore never evicts stale saved picks.

 

^{Reviewed by Cursor Bugbot for commit 338619c. Configure here.}