feat(context): restore the last used cluster on startup - #1467
feat(context): restore the last used cluster on startup#1467arlenvasconcelos wants to merge 1 commit into
Conversation
Radar starts on the cluster you were last working in instead of the kubeconfig's current-context. Every context switch is recorded in ~/.radar/settings.json and restored on the next start; an unresolvable memory is ignored so a stale pick can never keep Radar from starting. The record carries the kubeconfig file the context came from, not just its name. With several kubeconfigs loaded, two files can define the same context name and which one keeps the unqualified form depends on directory read order — matching by name alone would let a newly added file silently redirect the restore to a different cluster. Resolution matches the file first and falls back to the name only when that file has moved. Adds --context (and "context" in config.json) to choose the startup cluster explicitly; it wins over the memory and, once the cluster answers, becomes the remembered pick. "restoreLastContext": false turns the memory off and always starts on current-context. Nothing is recorded, restored, or served over /api/settings when auth is enabled or when serving through a cloud tunnel — there the kubeconfig context is shared state and one user's switch must not steer everyone else's next start. CAPI workload clusters are never remembered: their kubeconfig is a temp file that no longer exists on the next run. settings.Update now refuses to write over a settings file it could not read. Context switches call it automatically, so a single unreadable file would otherwise erase every other preference on the next switch.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 a0091af. Configure here.
| // viewer the operator's cluster name from whenever this $HOME last ran | ||
| // Radar locally. | ||
| loaded.LastContext = nil | ||
| } |
There was a problem hiding this comment.
Settings PUT leaks last context
Medium Severity
handleGetSettings clears lastContext when auth or cloud mode is on, but handlePutSettings returns the full updated settings—including lastContext—without the same strip. A theme or pinned-kinds save on a shared instance therefore exposes the operator’s previously remembered cluster name in the response body, contrary to the privacy rule this change documents.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit a0091af. Configure here.
| if name != "" && name == contextName && kubeconfigPath != "" { | ||
| return ContextRef{Name: name, SourceFile: kubeconfigPath, InFileName: name} | ||
| } | ||
| return ContextRef{Name: name} |
There was a problem hiding this comment.
Source file omitted for single dir
Medium Severity
ContextSourceFor only attaches sourceFile from the multi-file registry or from kubeconfigPath. When --kubeconfig-dir discovers exactly one file, init leaves the registry unset and never sets kubeconfigPath, so the remembered pick is stored as a bare name. A later-added kubeconfig that reuses that name can then silently restore a different cluster—the failure mode this feature set out to prevent.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit a0091af. Configure here.
nadaverell
left a comment
nadaverell
left a comment
There was a problem hiding this comment.
this I guess makes sense for desktop but may be counter intuitive for CLI-driven radar (or 'kubectl radar', or --diagnose invocations), where it is probably more expected to respect the kubectl context.
Posting a more detailed AI-assisted review in a sec but I think the change should be limited to desktop, maybe with a setting that users can opt in/out of this (choose between remembering last context and defaulting to current kubeconfig context). Claude/codex found a couple more things to note on handling deleted context etc.
The premise from #1454 is right: the Desktop app should reopen on the cluster the user was last working in. That is the natural behavior for a stateful GUI launched from the Dock, and the PR has made several thoughtful choices around recording only successful switches, surviving force-quits, avoiding CAPI temporary kubeconfigs, and not rewriting kubeconfig. The main concern is scope. The same remembered state currently also changes the default for Suggested product shape for consideration:
I don't think this necessarily needs to be split into multiple PRs—the important split is in the product semantics, not the contribution process. The concise target is: stateful Desktop, deterministic CLI, strict explicit overrides, and no silent wrong-cluster guesses. |
2 participants
Description
Radar starts on the cluster you were last working in instead of the kubeconfig's current-context. Every context switch is recorded in ~/.radar/settings.json and restored on the next start; an unresolvable memory is ignored so a stale pick can never keep Radar from starting.
The record carries the kubeconfig file the context came from, not just its name. With several kubeconfigs loaded, two files can define the same context name and which one keeps the unqualified form depends on directory read order — matching by name alone would let a newly added file silently redirect the restore to a different cluster. Resolution matches the file first and falls back to the name only when that file has moved.
Adds --context (and "context" in config.json) to choose the startup cluster explicitly; it wins over the memory and, once the cluster answers, becomes the remembered pick. "restoreLastContext": false turns the memory off and always starts on current-context.
Nothing is recorded, restored, or served over /api/settings when auth is enabled or when serving through a cloud tunnel — there the kubeconfig context is shared state and one user's switch must not steer everyone else's next start. CAPI workload clusters are never remembered: their kubeconfig is a temp file that no longer exists on the next run.
settings.Update now refuses to write over a settings file it could not read. Context switches call it automatically, so a single unreadable file would otherwise erase every other preference on the next switch.
Type of change
How has this been tested?
Describe the tests you ran to verify your changes.
Checklist
Related issues
Fixes #1454
Note
Medium Risk
Changes which Kubernetes cluster Radar connects to on startup and writes that pick to disk. Shared/auth/cloud paths are gated so one user’s switch cannot steer others, but a bad restore could still point a local session at the wrong cluster until they switch.
Overview
Radar now starts on the cluster you last used instead of the kubeconfig
current-context. Each UI context switch is written to~/.radar/settings.jsonaslastContext(name plus source file) so a later start reconnects there.--context(andconfig.json"context") wins over memory and, once the cluster answers, becomes the remembered pick."restoreLastContext": falsealways starts oncurrent-contextand stops recording switches. Stale or unknown names fall back tocurrent-context; CAPI temp kubeconfigs are never remembered.Memory is local single-user only: auth-enabled and cloud-tunnel instances neither persist nor restore, and
GET /api/settingsstripslastContext.settings.Updatenow refuses to overwrite an unreadable settings file so a context switch cannot wipe other preferences.Reviewed by Cursor Bugbot for commit a0091af. Bugbot is set up for automated code reviews on this repo. Configure here.