scadaproj/ZB.MOM.WW.Overview/CLAUDE.md

ZB.MOM.WW.Overview

The hosted family dashboard (Blazor Server). Build/test from this directory: dotnet build ZB.MOM.WW.Overview.slnx, dotnet test ZB.MOM.WW.Overview.slnx (fully offline).

Backlog / open work: lives in Gitea issues on dohertj2/scadaproj (tea issues list --repo dohertj2/scadaproj) — currently #14 (re-run the two OtOpcUa-blocked Phase 4 acceptance checks). The history below is a record, not a status tracker; file new follow-ups as issues.

Probe behaviour (P3 review fixes, scadaproj#48)

• The probe client does not follow redirects (Overview-003): an auth-wall 302 on /health/active maps to Unknown, not Active.
• Probes are not gated by the sweep (Overview-004): each target publishes its own result when it lands, and a target still being probed is skipped by later ticks, so a hung instance with a long TimeoutSeconds cannot stale the others.
• /health/active is probed whenever ready answered; HasActiveRole only gates the Active/Standby interpretation (Overview-005).

Index history (migrated from the scadaproj root CLAUDE.md)

Moved verbatim out of the scadaproj root CLAUDE.md on 2026-09-03 so it loads only when needed. This file is now the authoritative place for this history — append new entries here and keep the root index row short.

Besides the shared libraries, this repo hosts one application: ZB.MOM.WW.Overview/ — a Blazor Server single-pane dashboard that polls every registered instance's anonymous /health/ready + /health/active, caches one snapshot (pages never poll) and renders per-cluster state including the Akka leader chip, which is what the ZB.MOM.WW.Health 0.2.0/0.3.0 per-entry data work exists to feed. No login, strictly read-only, holds no credentials — a requirement, not an omission; it references no Auth/Audit/ Secrets package. Design + impl plan: docs/plans/2026-07-22-overview-dashboard-{design,impl-plan}.md (ledger 19/20; the open task is Phase 4 live acceptance, recorded in 41013dc as 7 of 9 design §9 checks passing, 2 blocked on an OtOpcUa rig redeploy → #14).

The Applications registry ships empty on purpose: a deployment supplying none fails startup naming the key rather than booting an empty dashboard. Per-deployment overlays are committed — appsettings.Docker.json (the local rigs, joined via external networks) and appsettings.Wonder.json.

Deployed to wonder-app-vd03 2026-08-11 (main @ 4f97e72) as that box's fifth app: service ZbOverview on :5320 under the shared NSSM, ASPNETCORE_ENVIRONMENT=Wonder, 5/5 instances Up. Two constraints worth carrying to any future box:

• Publish self-contained (-r win-x64 --self-contained true). wonder has no .NET 10 runtime — every app there carries its own. An FDD publish installs fine and then fails at service start.
• Leader resolution is per group (fixed 2026-11-09, Overview-002 / scadaproj#43). Leader-address → instance resolution matches on host only (Akka and HTTP ports differ by design). It used to scan the whole application, so co-located groups stole each other's chip — on vd03 ScadaBridge's site card claimed Leader · central, and the same happened on QA, where central-a and site-a both run on vq03 (the earlier note that QA "resolves as designed" was wrong). It now searches only the group's own members and keeps the raw Akka address when none matches. The vd03 127.0.0.1 BaseUrls are no longer needed for correctness (each vd03 group is single-node); they remain harmless. Two members of the same group on one host would still be indistinguishable by host.

QA runs an instance on EACH pair node — wonder-app-vq03:5320 and (since 2026-08-14) wonder-app-vq04:5320 — both watching the same registry, now 10 instances across 4 applications after the 2026-08-14 VQ04 singleton clone (MxGateway + HistorianGateway added on vq04; see deployment.md §7.1). It is the fastest way to read QA's whole topology. Its registry uses real FQDNs. Each QA group's two members are on distinct hosts (vq03/vq04), which per-group resolution needs; groups sharing a host no longer matter (see above).

Commands (from the index)

# ZB.MOM.WW.Overview  (~/Desktop/scadaproj/ZB.MOM.WW.Overview — the hosted family dashboard)
dotnet build ZB.MOM.WW.Overview.slnx
dotnet test  ZB.MOM.WW.Overview.slnx      # 177 tests, fully offline
cd docker && docker compose up -d --build # local rigs → http://localhost:5320 (start the rigs first)
# wonder deploy artifact — SELF-CONTAINED, the box has no .NET 10 runtime:
dotnet publish src/ZB.MOM.WW.Overview/ZB.MOM.WW.Overview.csproj -c Release -r win-x64 --self-contained true -o <out>

2026-10-01 — BTDB Manager registered on all three dashboards. appsettings.Wonder.json (vd03, committed) gains one instance wonder → http://127.0.0.1:9876 (management link http://10.220.157.247:9876/); the QA overlay E:\ApiInstall\Overview\app\appsettings.QA.json (deployed only, identical on vq03/vq04) gains vq03/vq04 → http://wonder-app-vq0N.zmr.zimmer.com:9876. All HasActiveRole: false (single unclustered Blazor app); /health/ready carries one sql entry (BT reachable). The registry is read at startup only, so ZbOverview was restarted on each node (previous files kept as *.bak-20261001T02xxxx). Verified: vd03 6/6 Up, vq03 and vq04 12/12 Up.