Virtual tags: TimerIntervalMs is ignored at runtime, so a timer-only virtual tag never evaluates (no deploy warning) #783

New Issue

2026-11-09T21:10:08-05:00

dohertj2 commented

2026-11-09 21:10:08 -05:00

Source: docs/reviews/2026-10-21/gates.md (master 7891b3cb), observations section — found running the #761 docker-dev gates on 1b9c36f3.

A virtual tag with TimerIntervalMs set and no ctx.GetTag dependency deploys cleanly, then sits at BadWaitingForInitialData indefinitely. VirtualTag.TimerIntervalMs isn't read at runtime: VirtualTagActor evaluates only on dependency changes, and there's no timer scheduler. The CalculationNoEffectiveTrigger DraftValidator rule (E4) covers Calculation tags only.

Fix one of two ways:

(a) implement timer-triggered evaluation for virtual tags, or
(b) reject or warn at deploy (a VirtualTagNoEffectiveTrigger rule) and stop exposing the field in the AdminUI.

Either way, add a test that a timer-only virtual tag either evaluates on its interval or is refused at deploy.

Source: docs/reviews/2026-10-21/gates.md (master 7891b3cb), observations section — found running the #761 docker-dev gates on 1b9c36f3. A virtual tag with `TimerIntervalMs` set and no `ctx.GetTag` dependency deploys cleanly, then sits at `BadWaitingForInitialData` indefinitely. `VirtualTag.TimerIntervalMs` isn't read at runtime: `VirtualTagActor` evaluates only on dependency changes, and there's no timer scheduler. The `CalculationNoEffectiveTrigger` DraftValidator rule (E4) covers Calculation tags only. Fix one of two ways: - (a) implement timer-triggered evaluation for virtual tags, or - (b) reject or warn at deploy (a `VirtualTagNoEffectiveTrigger` rule) and stop exposing the field in the AdminUI. Either way, add a test that a timer-only virtual tag either evaluates on its interval or is refused at deploy.

dohertj2 added the type:bug priority:p2 labels 2026-11-09 21:10:08 -05:00

dohertj2 referenced this issue

2026-11-09 21:10:24 -05:00

Review remediation 2026-10-21: run the Wave-4 integration gates (lanes A–G, H1, drivers) #761

dohertj2 commented

2026-11-09 21:28:24 -05:00

Fixed on master d9b95dcf by implementing the timer (option a). The repo already presents TimerIntervalMs as a working trigger: the entity docs, the DB check constraint (ChangeTriggered OR timer ≥ 50 ms), the AdminUI field, UnsTreeService's validation and the 2026-06-08 design all treat it that way. Only the runtime ignored it; the old TimerTriggerScheduler was deleted in #603 with no replacement.

EquipmentVirtualTagPlan now carries ChangeTriggered + TimerIntervalMs, and both are part of its equality, so an edit respawns the actor. The artifact decode was dropping them.
VirtualTagActor schedules a repeating tick in PreStart, clamped to 50 ms, and cancels it in PostStop. A tick that arrives while an async run (#779) is in flight is dropped, never stashed, so slow scripts don't build a backlog.
New deploy rule VirtualTagNoEffectiveTrigger: a hard error, same severity as E4.
docs/VirtualTags.md has a timer section.
Tests: VirtualTagActorTimerTests 5, DraftValidatorVirtualTagTriggerTests 5, plus an artifact-decode test. Each mutation turns tests red: no scheduling, stashing ticks instead of dropping, no cancel in PostStop, removing the validator call. Release build 0 warnings; Core.VirtualTags 16, Runtime 988, Configuration 219, AdminUI 1962, OpcUaServer.IntegrationTests 132 (AKKA_TEST_TIMEFACTOR=3).

⚠ Deploy note: the new rule refuses a deploy containing a virtual tag that has neither a timer nor a literal ctx.GetTag dependency. Such a tag never evaluated before either. Before rolling this to DEV/QA, check their ConfigDbs for such tags, or the first deploy after upgrade will be refused until they're fixed.

Fixed on master `d9b95dcf` by implementing the timer (option a). The repo already presents `TimerIntervalMs` as a working trigger: the entity docs, the DB check constraint (ChangeTriggered OR timer ≥ 50 ms), the AdminUI field, UnsTreeService's validation and the 2026-06-08 design all treat it that way. Only the runtime ignored it; the old `TimerTriggerScheduler` was deleted in #603 with no replacement. - `EquipmentVirtualTagPlan` now carries ChangeTriggered + TimerIntervalMs, and both are part of its equality, so an edit respawns the actor. The artifact decode was dropping them. - `VirtualTagActor` schedules a repeating tick in PreStart, clamped to 50 ms, and cancels it in PostStop. A tick that arrives while an async run (#779) is in flight is dropped, never stashed, so slow scripts don't build a backlog. - New deploy rule `VirtualTagNoEffectiveTrigger`: a hard error, same severity as E4. - docs/VirtualTags.md has a timer section. Tests: VirtualTagActorTimerTests 5, DraftValidatorVirtualTagTriggerTests 5, plus an artifact-decode test. Each mutation turns tests red: no scheduling, stashing ticks instead of dropping, no cancel in PostStop, removing the validator call. Release build 0 warnings; Core.VirtualTags 16, Runtime 988, Configuration 219, AdminUI 1962, OpcUaServer.IntegrationTests 132 (AKKA_TEST_TIMEFACTOR=3). ⚠ Deploy note: the new rule refuses a deploy containing a virtual tag that has neither a timer nor a literal `ctx.GetTag` dependency. Such a tag never evaluated before either. Before rolling this to DEV/QA, check their ConfigDbs for such tags, or the first deploy after upgrade will be refused until they're fixed.

dohertj2 closed this issue

2026-11-09 21:28:24 -05:00

dohertj2 referenced this issue

2026-11-09 21:39:30 -05:00

Gate findings: deploy TimedOut has null failureReason; quarantine logged as 'unknown' and shown as BadInternalError; rig PSK 'REVOKED' warning vs working dispatch #784

dohertj2 referenced this issue

2026-11-10 03:15:32 -05:00

A disabled VirtualTag (Enabled = false) is still deployed and evaluated #787

dohertj2 referenced this issue

2026-11-10 07:49:27 -05:00

Pre-upgrade ConfigDb checks for DEV/QA before deploying master ≥ 0e96dd08 (#783, #791, #792 deploy errors; #782 certs) #793

Sign in to join this conversation.