ScadaBridge/docs/deployment/deployment-records/2026-09-28-wonder-app-vq03-vq04-b3021e7c.md

Deployment record — wonder-app-vq03 + wonder-app-vq04 (QA) — 2026-09-28 — 2b9a7c3c → b3021e7c

Point-in-time record of a ScadaBridge binary + schema upgrade of the QA two-host topology (central pair central-a = vq03 10.220.158.2 / central-b = vq04 10.220.158.3 on :8085, site-a pair node-a/node-b on the same boxes, gRPC :8083, health :8084, LocalDb replication ON; services ScadaBridge-Central / ScadaBridge-Site out of E:\ApiInstall\ScadaBridge; shared ConfigDb ScadaBridge on wonder-sql-vq03). Same package as DEV (2026-09-28-wonder-app-vd03-fe89363b.md, second window) — read that for the build delta. Performed from the Mac with the winrm CLI (deployment-only scope: zip over SMB, one prep script per box, seven window calls), after the user confirmed boxes + build. Closes register row 126.

1. Binary + schema upgrade

Item	Value
Build deployed	main @ b3021e7c (from 2b9a7c3c, 2026-09-10) — all four nodes. Host + CLI ProductVersion 1.0.0+b3021e7c5ff68ba20abc510f644045c7dbbccd86 on both boxes.
Headline change	Computed-alarm IsMesReportable flag, site artifact staleness + Pending updates indicator, Gitea #36 reset-aware handshake, and the read-only allow-listed script Files global.
Artifact	E:\psrem-stage\b3021e7c\scadabridge.zip on both boxes, 125 585 217 B, SHA-256 5B7D7C68…2D66DF (re-verified on box; identical to vd03's); unpacked to …\unpacked (app 1029 files, cli 223).
EF migrations applied	2 (55 → 57) via sb-mig-55to57.sql (from→to, NOT idempotent, identical to vd03's) with sqlcmd -C -b -I on vq03, after asserting 55 / 20260909203046_…: 20260911135501_AddAlarmMesReportable, 20260914173147_AddSiteArtifactRevision. Both additive AddColumns — no data upgrade; a binary-only rollback to 2b9a7c3c would tolerate the extra columns, but the DB restore is the clean path.
New required config	None. The three appsettings*.json per box were kept and hash-matched after the swap (vq03 F94000B1/D1320FA8/4CBAF66C; vq04 F94000B1/2FD3EC4C/D0C1AF05 — vq03's Central file changed since 2026-09-10, user-held, restored as-is). Service registry env untouched (reg export of both keys to E:\psrem-stage\b3021e7c\_envbak-*.reg on each box). Script file access left OFF on QA (no SiteRuntime:ScriptFileAccess:AllowedRoots).
DB backup	F:\MSSQL\BACKUP\ScadaBridge_pre-b3021e7c_20260928T110651.bak on wonder-sql-vq03 (COPY_ONLY, CHECKSUM, COMPRESSION; RESTORE VERIFYONLY … WITH CHECKSUM valid), taken 11:06:55 with everything running.
Binary backup	app.bak.20260928T110907 / cli.bak.… on vq03, app.bak.20260928T110841 / cli.bak.… on vq04 (old 2b9a7c3c binaries); _appsettings-keep-<ts> alongside.
Notes on box	E:\ApiInstall\ScadaBridge\_DEPLOY-NOTES-b3021e7c.txt on each box.

Sequence (maintenance window)

Step	Local time
Stop Site vq04 (window opens)	11:07:34 → 11:08:04
Stop Site vq03	11:08:10 → 11:08:21
Stop Central vq04 + swap vq04	11:08:28 → 11:08:47
Stop Central vq03, migrate 55 → 57, swap vq03	11:08:54 → 11:09:13
Start Central vq03 (was active) → ready	11:09:13 → 11:09:27
Start Central vq04 → ready	11:09:35 → 11:09:43
Start Site vq03 → ready	11:09:52 → 11:10:00
Start Site vq04 → ready (window closes)	11:10:08 → 11:10:12

Downtime (first stop → last site ready): 2 min 38 s. Pairs stopped and started together.

Verification (from the Mac, HTTP + CLI)

• :8085 /health/ready 200 on both centrals — database Healthy, akka-cluster memberCount 2 / unreachable 0, required-singletons Healthy; /health/active 200 vq03 / 503 vq04 (same active node as before). Ready also proves the production-mode pending-migration check passed (57/57).
• :8084 /health/ready 200 on both sites — memberCount 2, localdb replicationConnected:true; /health/active 200 vq03 / 503 vq04.
• POST /management no-auth → 401 (unchanged).
• Snapshots: Z28061 / Z28062 244 attrs, 244 Good before (11:07) and after (11:11).
• Deploy Artifacts (last step, per row 126): deployment 999dee70…, site-a success; Sites.ArtifactRevisionHash = sha256:d79ba1a3…, ArtifactsDeployedAt 15:11:20Z — Sites page reads Current, not Never deployed.

2. Inbound method copied from DEV

SimpleAlarmStatusRequest (QA id 9) was a stub returning WasSuccessful=true, Alarms=[]. Replaced via api-method update with vd03's definition (id 9): script (BTDB dbo.Machine SAPID → code, trailing A/B stripped → Route.To(instance).Call("AlarmStatus", FlaggedOnly/IncludeAcked)), return definition (now required: [WasSuccessful, Alarms]), parameters {SAPID}, timeout 30 s — field-for-field identical to vd03 afterwards. Key-less smoke via flow-debug run-method: SAPID=000000 → Failed to find machine with SAPID '000000' (BTDB query ran, 113 ms); SAPID="" → same shape. No QA instance carries an AlarmStatus script yet, so a real SAPID answers Alarm status is not supported on machine '<code>' until the MES templates on QA gain it.

3. Rollback

1. Stop Site vq04 → vq03, Central vq04 → vq03; confirm no ZB.MOM.WW.ScadaBridge.Host process.
2. From vq03: RESTORE DATABASE [ScadaBridge] FROM DISK = 'F:\MSSQL\BACKUP\ScadaBridge_pre-b3021e7c_20260928T110651.bak' WITH REPLACE (reverts the two columns and the method-9 update).
3. Each box: app → app.failed, app.bak.<ts> → app; same for cli.
4. Start Central vq03 → vq04, then Site vq03 → vq04.

4. Outstanding

• ApiKeyStore:Provider still unset on the QA pair (per-node SQLite inbound keys) — unchanged.
• Housekeeping after soak: the 2026-09-10 and this deploy's app.bak.*/cli.bak.*/_appsettings-keep-* and E:\psrem-stage\{2b9a7c3c,b3021e7c} on both boxes.