[BUG] Substrate page misreports ate-api's state and which backend feeds each section

[Charlesthebird]

---

🤖 written by Claude (start)

🎯 Affected Service(s)

Multiple services / System-wide issue

🚦 Impact/Severity

Minor inconvenience

🐛 Bug Description

The Substrate page reports ate-api as connected while it is failing, blanks Kubernetes data when ate-api is absent, and tells the reader that actor templates come from Kubernetes when they come from ate-api. Three separate defects, all of them about which backend feeds what and whether it is working.

1. connected means "configured", not connected. The controller sets Enabled: s.ateClient != nil (service.go:197) — a client was built from config, no call made. The UI renders that as connected (SubstratePage.tsx:1664). So a failing ate-api shows a healthy tile above its own error banner:

tile   :: connected
banner :: Runtime actor state is incomplete … The actors and workers below come from
          ate-api, which answered with an error: ate-api list actors timed out after 5s

2. An unconfigured ate-api hides Kubernetes data. GetSubstrateStatus returns early when there is no ate-api client:

if s.ateClient == nil {
    return result, nil     // service.go:203
}

That is before listWorkerPools (service.go:216), which reads WorkerPool CRs from Kubernetes and needs no ate-api. A cluster with worker pools and no ate-api endpoint reports zero of them.

3. Actor templates are attributed to the wrong backend. The page subtitle (SubstratePage.tsx:1453) and the partial-data banner (:1606) both say actor templates come from Kubernetes and are "complete". They come from s.ateClient.ListActorTemplates (service.go:329), so during an ate-api failure the banner promises completeness for data that may be missing.

🔄 Steps To Reproduce

1. Run a controller with no substrate-ate-api-endpoint, with WorkerPool resources in the cluster. Open the Substrate page: Worker pools is empty, though the CRs exist.
2. Point it at an ate-api that times out. The ate-api tile reads connected while the banner says the read failed.

🤔 Expected Behavior

The tile distinguishes "not configured" from "configured but failing". Kubernetes-backed sections render whether or not ate-api is present. The page names the right source for each section.

🔍 Additional Context

Worth deciding together rather than piecemeal, since they trade against each other:

• A whole-page "ate-api not configured" state looks tempting but works against the current design. Once (2) is fixed, Worker pools has real content without ate-api, and substrate.spec.ts already asserts the opposite intent — "an unconfigured ate-api is explained, not reported as broken", because "enabled: false is a deployment choice, not a fault".
• The tile may not be worth keeping at all: both ate-api-backed tables already name the setting in their empty state, and the banner already covers failure. Three states (off / failing / connected) is the alternative.

---

📌 Update

The tile is gone as of 96798629 in #2706 — it was redundant when off, since both ate-api tables already name the setting, and wrong when configured-but-failing. That removes the misleading display, not the causes.

Still open here:

• The early return at service.go:203 still blanks Kubernetes-backed worker pools when ate-api is absent.
• The subtitle and banner still credit actor templates to Kubernetes.
• Is this page worth rendering without ate-api? Once the early return is fixed it has one card of four — worker pools — and two meaningful tiles. A whole-page "not configured" state was rejected on the grounds that unconfigured is a deployment choice rather than a fault, but that reasoning assumed more of the page survived than actually does.

---

🤖 written by Claude (end)