dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

deploy-gate: move deployed MES alarm scripts from ScriptAlarm.Severity to ScriptAlarm.Priority before deploying #129 #131

New Issue
Closed
opened 2026-11-12 14:05:40 -05:00 by dohertj2 · 3 comments
dohertj2 commented 2026-11-12 14:05:40 -05:00
Owner
Copy Link
Copy Source

Follow-up from #129 (dd4f1c2a). Since #129, ScriptAlarm.Severity is banded and runs higher = more urgent: MxAccess and computed rows read only 250/500/750/1000. The raw value, i.e. the pre-#129 Severity, is now on ScriptAlarm.Priority.

Gate: before any deploy that includes dd4f1c2a (DEV vd03, QA vq03/vq04), switch every deployed MES site script that reads a.Severity over to a.Priority in the same deploy. Otherwise the native 900–999 MES band selects nothing, and the MES Severity/MinSeverity/MaxSeverity values change.

Known scripts:

  • CvdReactor.SimpleAlarmStatus and CvdReactor.AlarmStatus: the band predicate, IsFlaggedForMES, and Severity = a.Severity. The pattern is in docs/plans/2026-06-30-mes-alarm-status-api.md §5.3, which is already updated.
  • vd03 SBTEST01/02 AlarmStatus site script: re-run docker/seed-mes-test-machine.sh (updated in dd4f1c2a), or replace a.Severity with a.Priority in its three places.
  • Grep the deployed scripts for any other Alarms.CurrentAsync/MesReportableAsync consumer that reads .Severity.

Verify: docker/verify-mes-test-machine.sh-style calls return the same Severity values and band selection as before the deploy.

Follow-up from #129 (`dd4f1c2a`). Since #129, `ScriptAlarm.Severity` is banded and runs higher = more urgent: MxAccess and computed rows read only 250/500/750/1000. The raw value, i.e. the pre-#129 `Severity`, is now on `ScriptAlarm.Priority`. **Gate:** before any deploy that includes `dd4f1c2a` (DEV vd03, QA vq03/vq04), switch every deployed MES site script that reads `a.Severity` over to `a.Priority` in the same deploy. Otherwise the native 900–999 MES band selects nothing, and the MES `Severity`/`MinSeverity`/`MaxSeverity` values change. Known scripts: - `CvdReactor.SimpleAlarmStatus` and `CvdReactor.AlarmStatus`: the band predicate, `IsFlaggedForMES`, and `Severity = a.Severity`. The pattern is in `docs/plans/2026-06-30-mes-alarm-status-api.md` §5.3, which is already updated. - vd03 SBTEST01/02 `AlarmStatus` site script: re-run `docker/seed-mes-test-machine.sh` (updated in `dd4f1c2a`), or replace `a.Severity` with `a.Priority` in its three places. - Grep the deployed scripts for any other `Alarms.CurrentAsync`/`MesReportableAsync` consumer that reads `.Severity`. Verify: `docker/verify-mes-test-machine.sh`-style calls return the same `Severity` values and band selection as before the deploy.
dohertj2 added the type:deploy-gatepriority:p2 labels 2026-11-12 14:05:40 -05:00
dohertj2 commented 2026-11-12 23:19:36 -05:00
Author
Owner
Copy Link
Copy Source

Deploy prep done, not applied (commit a92a418d on main). Plan, original and fixed bodies, and apply.sh check|apply|rollback 131: docs/deployment/deploy-prep/2026-11-12-gates-52-131/.

Inventory. From a read-only export on 2026-11-12. I searched every template script and inbound method for .Severity on a ScriptAlarm and for Alarms.* calls. instance diff shows no stale instance, so the deployed scripts are these template bodies.

  • DEV vd03: one script. TestMesMachine.AlarmStatus (template 30, script 42; SBTEST01/02) reads a.Severity in exactly the 3 known places. Its body is byte-identical to the pre-dd4f1c2a seed-mes-test-machine.sh.
  • DEV vd03, CvdReactor: it has no AlarmStatus or SimpleAlarmStatus script. The §5.3 pattern was never deployed.
  • QA: nothing to change. There is no TestMesMachine. CvdReactor.AlarmStatus (script 39) is a stub returning Alarms = [].
  • The inbound SimpleAlarmStatusRequest and AlarmStatusRequest methods only pass MinSeverity and MaxSeverity through as arguments, so neither env needs a change there.

Correction to the premise. The old body does not stop compiling on main: ScriptAlarm.Severity still exists. It keeps running and returns banded values with inverted filters. The direction that fails to compile is the reverse: the fixed body uses a.Priority, and the deployed DEV build 424db155 doesn't have it. On the rig, a body with an unknown ScriptAlarm member saves fine, and its deploy is refused with Pre-deployment validation failed: … ScriptCompilation.

Order. DEV only. Deploy the dd4f1c2a+ binary to central and site, then run apply.sh apply 131 in the same window.

  • Script applied before the binary: the instance deploys are refused. Run rollback 131 --no-deploy to put the template back.
  • Binary without the script: MES output is wrong (below).

Rig evidence. Main binary; the rig's TestMesMachine AlarmStatus started byte-identical to DEV script 42. I tripped HighVacuumFault (priority 800), DoorOpenAlarm (300) and SensorFault (700) with flow-debug run-script.

Query Old body on main Fixed body on main
all (SBTEST01) Door 750, HighVac 250, Sensor 500 Door 300, HighVac 800, Sensor 700
MinSeverity=500 Door, Sensor HighVac, Sensor
SBTEST02 FlaggedOnly + MaxSeverity=750 HighVac, Sensor Sensor
  • The fixed column matches the pre-#129 expectations in verify-mes-test-machine.sh (C3, C7, C9).
  • Guard: apply.sh refused with an unknown live body.
  • Round trip: rollback then apply returned the same revision hashes.
  • Rig end state: SBTEST01/02 are left on the fixed body.

Verify on DEV after applying: docker/verify-mes-test-machine.sh, groups C and D. Not closing: applying this is a deploy.

**Deploy prep done, not applied** (commit `a92a418d` on `main`). Plan, original and fixed bodies, and `apply.sh check|apply|rollback 131`: [`docs/deployment/deploy-prep/2026-11-12-gates-52-131/`](https://gitea.dohertylan.com/dohertj2/ScadaBridge/src/branch/main/docs/deployment/deploy-prep/2026-11-12-gates-52-131/README.md). **Inventory.** From a read-only export on 2026-11-12. I searched every template script and inbound method for `.Severity` on a ScriptAlarm and for `Alarms.*` calls. `instance diff` shows no stale instance, so the deployed scripts are these template bodies. - **DEV vd03: one script.** `TestMesMachine.AlarmStatus` (template 30, script 42; SBTEST01/02) reads `a.Severity` in exactly the 3 known places. Its body is byte-identical to the pre-`dd4f1c2a` `seed-mes-test-machine.sh`. - **DEV vd03, CvdReactor:** it has **no** `AlarmStatus` or `SimpleAlarmStatus` script. The §5.3 pattern was never deployed. - **QA: nothing to change.** There is no TestMesMachine. `CvdReactor.AlarmStatus` (script 39) is a stub returning `Alarms = []`. - The inbound `SimpleAlarmStatusRequest` and `AlarmStatusRequest` methods only pass MinSeverity and MaxSeverity through as arguments, so neither env needs a change there. **Correction to the premise.** The old body does **not** stop compiling on `main`: `ScriptAlarm.Severity` still exists. It keeps running and returns banded values with inverted filters. The direction that fails to compile is the reverse: the fixed body uses `a.Priority`, and the deployed DEV build `424db155` doesn't have it. On the rig, a body with an unknown ScriptAlarm member saves fine, and its deploy is refused with `Pre-deployment validation failed: … ScriptCompilation`. **Order.** DEV only. Deploy the `dd4f1c2a`+ binary to central and site, then run `apply.sh apply 131` in the same window. - **Script applied before the binary:** the instance deploys are refused. Run `rollback 131 --no-deploy` to put the template back. - **Binary without the script:** MES output is wrong (below). **Rig evidence.** Main binary; the rig's TestMesMachine AlarmStatus started byte-identical to DEV script 42. I tripped HighVacuumFault (priority 800), DoorOpenAlarm (300) and SensorFault (700) with `flow-debug run-script`. | Query | Old body on main | Fixed body on main | |---|---|---| | all (SBTEST01) | Door 750, HighVac 250, Sensor 500 | Door 300, HighVac 800, Sensor 700 | | MinSeverity=500 | Door, Sensor | HighVac, Sensor | | SBTEST02 FlaggedOnly + MaxSeverity=750 | HighVac, Sensor | Sensor | - **The fixed column matches the pre-#129 expectations** in `verify-mes-test-machine.sh` (C3, C7, C9). - **Guard:** `apply.sh` refused with an unknown live body. - **Round trip:** `rollback` then `apply` returned the same revision hashes. - **Rig end state:** SBTEST01/02 are left on the fixed body. **Verify on DEV after applying:** `docker/verify-mes-test-machine.sh`, groups C and D. Not closing: applying this is a deploy.
dohertj2 commented 2026-11-13 07:22:44 -05:00
Author
Owner
Copy Link
Copy Source

Applied and verified on DEV vd03, 2026-11-13, in the same window as the 8e32f353 binary (which contains dd4f1c2a).

  • Baseline before the deploy, on the old binary with the old body: verify-mes-test-machine.sh groups C+D gave PASS 13/13. C13 was skipped because SAPID 103559 routes to Z28061.
  • Right after the swap I ran apply.sh apply 131:
    • TestMesMachine.AlarmStatus (template 30, script 42) went from ORIGINAL to FIXED (a.Severity → a.Priority, 3 places).
    • The metadata read back unchanged.
    • SBTEST01 and SBTEST02 redeployed as deployments 95 and 96, status 2.
  • The same harness after the apply: PASS 13/13. C3 Severity == 800, C7 (MinSeverity 500) and C9 (MaxSeverity 750) select the same alarms as on the pre-#129 binary. Alarm sources were reset (D1).
  • QA needs nothing (see the deploy-prep pack). #52 was not applied.

Record: docs/deployment/deployment-records/2026-11-13-wonder-app-vd03-8e32f353.md (581e25ca). Closing.

https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi

**Applied and verified on DEV vd03, 2026-11-13**, in the same window as the `8e32f353` binary (which contains `dd4f1c2a`). - Baseline before the deploy, on the old binary with the old body: `verify-mes-test-machine.sh` groups C+D gave **PASS 13/13**. C13 was skipped because SAPID 103559 routes to Z28061. - Right after the swap I ran `apply.sh apply 131`: - `TestMesMachine.AlarmStatus` (template 30, script 42) went from ORIGINAL to FIXED (`a.Severity` → `a.Priority`, 3 places). - The metadata read back unchanged. - SBTEST01 and SBTEST02 redeployed as deployments 95 and 96, status 2. - The same harness after the apply: **PASS 13/13**. C3 `Severity == 800`, C7 (MinSeverity 500) and C9 (MaxSeverity 750) select the same alarms as on the pre-#129 binary. Alarm sources were reset (D1). - QA needs nothing (see the deploy-prep pack). #52 was **not** applied. Record: `docs/deployment/deployment-records/2026-11-13-wonder-app-vd03-8e32f353.md` (`581e25ca`). Closing. https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi
dohertj2 commented 2026-11-13 08:14:55 -05:00
Author
Owner
Copy Link
Copy Source

QA vq03/vq04 is on 8e32f353 (2026-11-13, record 8ba5d5d7). No #131 step was needed there, as found in the pack (re-checked 07:05): QA has no TestMesMachine, CvdReactor.AlarmStatus is a stub that doesn't read .Severity, and no API method reads alarms.

**QA vq03/vq04 is on `8e32f353` (2026-11-13, record `8ba5d5d7`). No #131 step was needed there**, as found in the pack (re-checked 07:05): QA has no `TestMesMachine`, `CvdReactor.AlarmStatus` is a stub that doesn't read `.Severity`, and no API method reads alarms.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Blocked by dependency or external hold
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 type:bug
Defect in shipped behaviour
 type:debt
Technical debt / hygiene
 type:deploy-gate
Rollout/deploy/migration step not yet done on an environment
 type:docs
Documentation work
 type:feature
Feature implementation
 type:followup
Follow-up deferred from a plan, PR or gate
 type:infra
Infrastructure and scaffolding
 type:review-finding
Unfixed finding from an architecture/code review
 type:test
Test work
No Label priority:p2 type:deploy-gate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/ScadaBridge#131
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?