Describe the bug
On a fresh make all install (no VM, run locally with --no-tunnel --private), the host agent auto-discovers Kubernetes contexts from the local ~/.kube/config at startup (separate from the explicit "Clusters → + Connect cluster" upload flow). When one of those local contexts can't actually be reached (stale/deleted kind/minikube cluster still present in kubeconfig), the sidebar entry never resolves, it shows Discovering infrastructure… indefinitely with no error message, no timeout indication, nothing actionable.
Steps to reproduce
- Have a
~/.kube/config context pointing at a cluster that no longer exists or isn't reachable (e.g. a kind cluster you deleted, or forgot was there)
git clone + make all + ./bin/infracanvas serve --no-tunnel --private- Open the dashboard, click the cluster entry in the sidebar
- Canvas shows
Discovering infrastructure… and never progresses
Expected behavior
Either it fails fast with a clear error (same as the explicit remote-cluster-upload flow shows an error status), or it doesn't list an unreachable context as if it's live in the first place.
Investigation so far
Checked pkg/discovery/kubernetes/discovery.go: IsAvailable() has an 8s timeout, REST config defaults to a 30s timeout, so the backend itself shouldn't hang indefinitely. This points at a missing error-surfacing path between pkg/orchestrator's Kubernetes discovery and the frontend for this specific auto-discovered-local-context code path, most likely the failed/timed-out discovery attempt just isn't being sent to the browser as a distinct error state for this flow. Note this is a different code path than #7 (that one's about the explicit kubeconfig-upload "Clusters" flow, which already shows an error status, just an incorrect one); this is the automatic local-context discovery baked into the host agent itself, which currently shows no error state at all.
Additional context
Related to #7 but not a duplicate, different code path, different symptom (indefinite spinner vs. incorrect error status).
Describe the bug
On a fresh
make allinstall (no VM, run locally with--no-tunnel --private), the host agent auto-discovers Kubernetes contexts from the local~/.kube/configat startup (separate from the explicit "Clusters → + Connect cluster" upload flow). When one of those local contexts can't actually be reached (stale/deletedkind/minikube cluster still present in kubeconfig), the sidebar entry never resolves, it showsDiscovering infrastructure…indefinitely with no error message, no timeout indication, nothing actionable.Steps to reproduce
~/.kube/configcontext pointing at a cluster that no longer exists or isn't reachable (e.g. akindcluster you deleted, or forgot was there)git clone+make all+./bin/infracanvas serve --no-tunnel --privateDiscovering infrastructure…and never progressesExpected behavior
Either it fails fast with a clear error (same as the explicit remote-cluster-upload flow shows an
errorstatus), or it doesn't list an unreachable context as if it's live in the first place.Investigation so far
Checked
pkg/discovery/kubernetes/discovery.go:IsAvailable()has an 8s timeout, REST config defaults to a 30s timeout, so the backend itself shouldn't hang indefinitely. This points at a missing error-surfacing path betweenpkg/orchestrator's Kubernetes discovery and the frontend for this specific auto-discovered-local-context code path, most likely the failed/timed-out discovery attempt just isn't being sent to the browser as a distinct error state for this flow. Note this is a different code path than #7 (that one's about the explicit kubeconfig-upload "Clusters" flow, which already shows anerrorstatus, just an incorrect one); this is the automatic local-context discovery baked into the host agent itself, which currently shows no error state at all.Additional context
Related to #7 but not a duplicate, different code path, different symptom (indefinite spinner vs. incorrect
errorstatus).