None of these were fixture absence. Each is a guard that went quietly wrong and
then reported the wrong thing.
PrimaryGateFailoverTests — per-cluster mesh Phase 6 (a2c5d57f) moved
RedundancyStateActor out of WithOtOpcUaControlPlaneSingletons into its own
cluster-role-scoped registration, made from Program.cs's DRIVER branch. The
harness models a fused admin,driver node but was never updated, so from that
commit onward NO node it built spawned the singleton: nothing published
redundancy-state, both nodes sat at "role unknown" forever, and the test polled
45s and timed out. The test's own summary calls this its negative control for a
broken redundancy-topic subscribe — it fired correctly, at the harness rather
than at production. Second time this shape has bitten the harness; the
AddOtOpcUaRuntime note a few lines up records the first.
DriverProbeRegistrationTests — the expected driver set was a hand-written array
kept in sync by comment, and it drifted when Sql (9b5a9687) and Mqtt (f79d13e2)
shipped. It failed as "12 where 10 expected", which names neither driver and
reads as if the probes were wrong. It also could not catch the direction that
matters: a driver type registered with no probe passed silently, because a
hand-written list only grows when someone remembers, and this test exists for
the case where nobody did. Now derived from DriverTypeNames.All, both
directions, plus an explicit case-drift test for the two types whose AdminUI key
differs in case from the constant (TwinCat/TwinCAT, Focas/FOCAS) — which the
derived tests cannot cover, since they compare the constants to themselves.
DriverProbeHandshakeE2eTests.AbCip_Green_AgainstSim — the probe config still used
the retired v2 `Tags: [{DeviceHostAddress, TagPath}]` shape, so
AbCipDriverOptions.RawTags bound empty, the probe fell through to its
@raw_cpu_type system-tag fallback, and ab_server answered ErrorBadParam. The test
has therefore spent the whole v3 migration exercising the one path its own
comment says it does not exercise. Rewritten to the v3 RawTags shape, and the
assertion tightened from ShouldContain("CIP session OK") to an exact match:
the probe's two green messages both contain that substring, so the loose form
would go green again the moment the config merely reached the controller,
whether or not the authored tag resolved.
Falsified each: drop the MTConnect probe (2 red, by name), remove the harness
singleton registration (back to the 48s "role unknown" timeout), break the
RawTags key (back to ErrorBadParam).
Host.IntegrationTests 211 passed / 4 skipped / 0 failed, against live fixtures on
10.100.0.35.
Still red and NOT addressed here: the AbLegacy integration suite (4 tests). Its
fixture is genuinely down, but it hard-fails instead of skipping because the
AbCip ControlLogix container holds :44818 — the reachability guard cannot tell
"my ab_server" from "someone else's", so SkipReason stays null and SLC500-mode
PCCC runs against a ControlLogix. Needs either distinct fixture ports or a
family-aware guard; both are shared-infrastructure changes.
Claude-Session: https://claude.ai/code/session_015p7wGqy3YpZNCpDzTpGMKo
Register the MTConnect factory + probe with the Host, add the
DriverTypeNames.MTConnect constant, and keep DriverTypeNamesGuardTests green.
- DriverTypeNames: new MTConnect const + appended to All.
- DriverFactoryBootstrap: MTConnectDriverFactoryExtensions.Register in
Register(...) at the default Tier A (managed HttpClient/XML, in-process;
Tier C is the only tier arming process-recycle, wrong here), and
TryAddEnumerable(IDriverProbe -> MTConnectDriverProbe) in
AddOtOpcUaDriverProbes so the probe reaches admin-only nodes (the
admin-pinned Test-Connect singleton) without double-registering on a
fused admin,driver node.
- Host.csproj: ProjectReference to Driver.MTConnect (required to compile
the Register call).
- Core.Abstractions.Tests.csproj: ProjectReference to Driver.MTConnect so
the guard's bin scan discovers the factory. This and the constant MUST
land together -- verified RED (2/4 facts) with the constant alone.
- DriverProbeRegistrationTests: MTConnect added to AdminUiDriverTypeKeys;
its idempotency fact asserts distinct-probe-count and goes RED without
this (and RED if TryAddEnumerable is downgraded to AddSingleton).
Reconciles all four "MTConnect" literals onto the one constant: the
factory's DriverTypeName, MTConnectDriver.DriverType, and
MTConnectDriverProbe.DriverType now all alias DriverTypeNames.MTConnect
(no circular reference -- Core.Abstractions is a leaf both driver
projects already reference). This is the repo's TwinCat/Focas anti-drift
convention.
Pre-existing stale test surfaced by Batch 4's full gate (Batch 2/3 gates were
live-/run and never ran Host.IntegrationTests): Batch 2 registered CalculationProbe
in DriverFactoryBootstrap (9 probes) but AddOtOpcUaDriverProbes_is_idempotent's
AdminUiDriverTypeKeys still listed 8, so distinctTypes(9) != Length(8). Calculation
is a real DriverTypeNames.Calculation pseudo-driver with a probe; add it and refresh
the now-stale *DriverPage.razor comment (that routed flow retired in Batch 2). Not a
Batch-4 code change — a test-correctness fix.
Claude-Session: https://claude.ai/code/session_01LVneM3eh1UtJxEisFXgmox
The HistorianGateway driver is now the sole historian read/write+alarm backend, so the
Wonderware sidecar projects are dead code. Removes the 5 Wonderware projects (driver,
.Client, .Client.Contracts, + their 2 test projects) from the solution and tree, and fully
retires the vestigial 'Historian.Wonderware' driver type (UI/probe-only; it had no driver
factory): the Host probe registration, the AdminUI driver-config surface (driver page,
tag-config editor/model/validator entry, address picker/builder, driver-type catalog +
dropdown + edit-router entries), and their tests. Prunes the now-unused Wonderware
connection fields (Host/Port/UseTls/ServerCertThumbprint/SharedSecret) from
AlarmHistorianOptions (keeping Enabled + the SQLite store-and-forward knobs) and refreshes
the stale XML docs that named Wonderware as the production backend.
Claude-Session: https://claude.ai/code/session_012SDSQ3AcaXqPcBtDESBRii
Both bugs surfaced only on split-role deployments (the MAIN cluster's
admin-only nodes), where the AdminUI runs without the driver role.
- Test Connect returned "No probe registered" for every driver: the
IDriverProbe set was registered only under the driver role, but the
admin-operations singleton that consumes it is pinned to admin. Extract
AddOtOpcUaDriverProbes() (idempotent via TryAddEnumerable) and call it
in the hasAdmin path too.
- Live driver-status/alerts/script-log panels showed "SignalR error:
Connection refused": these Blazor Server components opened a HubConnection
to their own hub via the browser's public URL, which server-side code
can't reach behind Traefik (host :9200 -> container :9000). Read the
in-process source directly instead -- DriverStatus via
IDriverStatusSnapshotStore.SnapshotChanged, Alerts/ScriptLog via a new
IInProcessBroadcaster<T>. Fleet status was unaffected (reads DB/ActorSystem).
Adds unit tests for probe registration, the snapshot-store event, and the
broadcaster.
Joseph Doherty