fix(hosts): a driver that never built a tag table reports NO ANSWER, not zero skips
Found on the docker-dev live gate, not in tests. Two drivers that faulted during initialise (rtu-gate, opcua1) each rendered "0 tags" on /hosts against two authored tags apiece, because a ledger that had never committed returned SkippedTagReport.Empty. A zero report is a positive claim -- "this driver skipped nothing" -- and making it on behalf of a driver that never got as far as looking is exactly the quiet inaccuracy #541 exists to remove. GetSkippedTags() and SkippedTagLedger.Snapshot() now return null until the first committed build, so the column renders the same em-dash it already used for a driver that cannot report at all. Both are 'no answer'; neither is 'nothing skipped'. Knock-on: a FOCAS driver whose only init threw now reports null rather than a zero report, which is strictly more honest than the assertion the test originally made.
This commit is contained in:
@@ -234,8 +234,11 @@ else
|
||||
Healthy, Errors/5 min stays 0, Last error stays empty, and Last
|
||||
read keeps advancing off the tags that DID map. On the Makino in
|
||||
#540 that read as a perfectly healthy driver ignoring 20 of its 22
|
||||
tags. "—" means the driver cannot report skips, which is distinct
|
||||
from reporting none. *@
|
||||
tags. "—" means NO ANSWER — either the driver cannot report skips,
|
||||
or it faulted before building a tag table — which is distinct from
|
||||
the positive claim "this driver skipped nothing". A pre-fix build
|
||||
rendered "0 tags" for two faulted drivers on the docker-dev rig
|
||||
that had two authored tags apiece. *@
|
||||
@if (d.SkippedTags is null)
|
||||
{
|
||||
<span class="text-muted">—</span>
|
||||
|
||||
Reference in New Issue
Block a user