DriverInstanceResilienceStatus: dead table — same defect as #521, keep or delete #524

New Issue

2026-07-30T04:56:41-04:00

dohertj2 commented

2026-07-30 04:56:41 -04:00

Found while resolving #521, and deliberately not folded into it — deleting a second table was beyond what that issue asked for.

What is true today

DriverInstanceResilienceStatus has no writer and no reader. The only reference in the whole repo is the DriverInstanceResilienceStatuses DbSet declaration in OtOpcUaConfigDbContext. Every deployment's copy of this table is empty.
Its doc-comment described two components that were never built: "rows are written by the runtime via a HostedService that samples the tracker at a configurable interval (default 5 s)" and "The Admin UI left-joins this table on DriverHostStatus for display". There is no sampler, and that join exists in no razor file.
It also referenced DriverHostStatus, which no longer exists — dropped in #521.
It cited MemoryTracking + MemoryRecycle as its data sources; both were deleted in #522.

The doc-comment has been rewritten to state the truth. The entity itself is untouched.

Why it is dead for exactly the reason #521's table was

Per-cluster mesh Phase 4 gates AddOtOpcUaConfigDb on the admin role, so a driver-only node has no ConfigDb connection to write rows with. Any per-node runtime status table has the same problem.

The live data already exists and does not go through SQL: resilience state reaches the AdminUI as DriverResilienceStatusChanged over the Phase 5 gRPC telemetry stream into the in-memory IDriverResilienceStatusStore — the same channel #521 adopted for per-host connectivity.

The decision

(a) Delete it. Drop the entity, the DbSet, the model config, and the table (migration), mirroring #521's DropDriverHostStatusTable. The telemetry channel already delivers this data; the table is a permanently-empty schema object whose doc-comment misled twice.

(b) Keep it as a durable history sink. The one thing telemetry does not give you is history across a central restart — the in-memory store is last-value-only. If breaker-trip history is wanted, this table is a reasonable home, but it would need a central-side writer fed by the telemetry stream (not a driver-node writer, which Phase 4 rules out).

(a) is the straightforward read given nothing has needed it. Worth an explicit decision rather than inference, same as #521 and #522.

Found while resolving #521, and **deliberately not folded into it** — deleting a second table was beyond what that issue asked for. ## What is true today - `DriverInstanceResilienceStatus` has **no writer and no reader**. The only reference in the whole repo is the `DriverInstanceResilienceStatuses` DbSet declaration in `OtOpcUaConfigDbContext`. Every deployment's copy of this table is empty. - Its doc-comment described two components that were never built: *"rows are written by the runtime via a HostedService that samples the tracker at a configurable interval (default 5 s)"* and *"The Admin UI left-joins this table on DriverHostStatus for display"*. There is no sampler, and that join exists in no razor file. - It also referenced `DriverHostStatus`, which **no longer exists** — dropped in #521. - It cited `MemoryTracking` + `MemoryRecycle` as its data sources; both were **deleted in #522**. The doc-comment has been rewritten to state the truth. The entity itself is untouched. ## Why it is dead for exactly the reason #521's table was Per-cluster mesh Phase 4 gates `AddOtOpcUaConfigDb` on the `admin` role, so a **driver-only node has no ConfigDb connection to write rows with**. Any per-node runtime status table has the same problem. **The live data already exists and does not go through SQL:** resilience state reaches the AdminUI as `DriverResilienceStatusChanged` over the Phase 5 gRPC telemetry stream into the in-memory `IDriverResilienceStatusStore` — the same channel #521 adopted for per-host connectivity. ## The decision **(a) Delete it.** Drop the entity, the DbSet, the model config, and the table (migration), mirroring #521's `DropDriverHostStatusTable`. The telemetry channel already delivers this data; the table is a permanently-empty schema object whose doc-comment misled twice. **(b) Keep it as a durable history sink.** The one thing telemetry does *not* give you is history across a central restart — the in-memory store is last-value-only. If breaker-trip history is wanted, this table is a reasonable home, but it would need a **central-side** writer fed by the telemetry stream (not a driver-node writer, which Phase 4 rules out). (a) is the straightforward read given nothing has needed it. Worth an explicit decision rather than inference, same as #521 and #522.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#524