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.

dohertj2 referenced this issue from a commit

2026-07-31 04:25:22 -04:00

refactor(config): drop the dead DriverInstanceResilienceStatus table (#524)

dohertj2 referenced this issue from a commit

2026-07-31 04:25:22 -04:00

docs(deferment): #524 closed; #525 recommendation withdrawn mid-execution

dohertj2 referenced this issue from a commit

2026-07-31 04:25:22 -04:00

merge: close #524 (drop dead resilience-status table)

dohertj2 closed this issue

2026-07-31 04:25:22 -04:00

dohertj2 commented

2026-07-31 04:25:40 -04:00

Resolved on master ba85e871 — option (a), delete.

Everything this issue asserted held up on re-verification, and the deciding fact was that the live data was never actually missing:

IDriverResilienceStatusStore is genuinely consumed — DriverStatusPanel.razor injects it, fed by both DriverResilienceStatusBridge (DPS) and TelemetryDialSupervisor (gRPC). So resilience counters already reach the AdminUI; the table contributed nothing but a permanently-empty schema object whose doc-comment misled twice.
Option (b) — keeping it as a durable history sink — is not blocked by deleting. Breaker history across a central restart is the one thing the last-value-only store cannot give, but it would need a central-side writer fed by the telemetry stream, with a different key and shape. An empty table bought nothing toward it.

Dropped: the entity, the DbSet, the model config, and the table (migration DropDriverInstanceResilienceStatusTable). Down() recreates it exactly, and the scaffolder's data-loss warning cannot bite on a table nothing ever inserted into.

Also corrected en route: DriverResilienceStatusTracker's doc-comment claimed CurrentInFlight fed DriverInstanceResilienceStatus.CurrentBulkheadDepth "until the full telemetry observer lands". The observer landed in Phase 5; the table never had a writer.

SchemaComplianceTests caught the drop as intended — that guard is live, not decorative (it failed when #521's table was removed from the DbContext without updating it).

Resolved on master `ba85e871` — **option (a), delete.** Everything this issue asserted held up on re-verification, and the deciding fact was that the live data was never actually missing: - `IDriverResilienceStatusStore` **is genuinely consumed** — `DriverStatusPanel.razor` injects it, fed by both `DriverResilienceStatusBridge` (DPS) and `TelemetryDialSupervisor` (gRPC). So resilience counters already reach the AdminUI; the table contributed nothing but a permanently-empty schema object whose doc-comment misled twice. - Option (b) — keeping it as a durable history sink — is not blocked by deleting. Breaker history across a central restart is the one thing the last-value-only store cannot give, but it would need a **central-side** writer fed by the telemetry stream, with a different key and shape. An empty table bought nothing toward it. Dropped: the entity, the DbSet, the model config, and the table (migration `DropDriverInstanceResilienceStatusTable`). `Down()` recreates it exactly, and the scaffolder's data-loss warning cannot bite on a table nothing ever inserted into. Also corrected en route: `DriverResilienceStatusTracker`'s doc-comment claimed `CurrentInFlight` fed `DriverInstanceResilienceStatus.CurrentBulkheadDepth` *"until the full telemetry observer lands"*. The observer landed in Phase 5; the table never had a writer. `SchemaComplianceTests` caught the drop as intended — that guard is live, not decorative (it failed when #521's table was removed from the DbContext without updating it).

dohertj2 referenced this issue

2026-10-08 02:31:16 -04:00

Docs: correct stale claims and bookkeeping #624

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#524