docs(index): vd03 DEV deploys 2026-11-11 — mxaccessgw 2b13564e, HistorianGateway ea9f21c, ScadaBridge 424db155

2026-11-11 16:50:58 -05:00
parent 601f7ae0e6
commit 1c6fe5793b
4 changed files with 9 additions and 3 deletions
@@ -82,3 +82,5 @@ for persistence evidence.
 - **2026-11-10 (#58 closed):** the .NET client now verifies TLS certificates by default. `AllowUntrustedServerCertificate` (default false) replaces `RequireCertificateValidation`, and the CLI gains `--allow-untrusted`. This is breaking and Unreleased, and ships at the 1.0.0 cut, which has not been made. PR #130 → `e432191`. OtOpcUa adapter one-line rename tracked in historiangw#131.
 - **2026-11-10 — Contracts + Client 1.0.0 released** (PR #132 → `ea9f21c`, tag `v1.0.0`, both on the `dohertj2-gitea` feed). It is the first major. **Breaking:** the client verifies TLS certificates by default (`AllowUntrustedServerCertificate`, #58). It also carries #25 (WriteLiveValues) and #126 (GetStoreForwardStatus during an outage). No wire change: still `historian_gateway.v1`. OtOpcUa is moving to it now and needs a one-line adapter rename (historiangw#131). The Java client stays at 0.2.0; it already verifies by default and is unaffected by the wire.
 - **2026-11-11:** OtOpcUa adopted Contracts/Client 1.0.0 with the adapter rename (`230cef4e build: adopt HistorianGateway 1.0 TLS options`, on origin/master); historiangw#131 closed. The only open historiangw issue is #78 (the DEV/QA deploy, blocked by the wonder-box hold).
+
+- **2026-11-11 deployed `ea9f21c` to wonder-app-vd03 (DEV)** (was `d8d890c`, the SQL-era build). Owner-approved WinRM deploy: SMB-staged self-contained win-x64, preflight test boot on 15220/15221 against store copies, swap 6.5 s downtime, verify 0 FAIL (gRPC probe/browse/read-raw as OtOpcUa, bogus key refused). Config unchanged (already `Transport=RemoteGrpc` → wonder-sql-vd03:32565); inert `RuntimeDb` line removed from appsettings.Production.json. Backups `Server.bak.20261111T164035`, `_databak-pre-ea9f21c-…`, `_regbak-…`. Carried-over risks: `AllowUntrustedServerCertificate=true` (#91), personal historian account.
@@ -460,3 +460,5 @@ AddRoute of the dev Mac (`oee-tagdump-mac`, `10.181.206.245.1.1`) on the two tes
    - **#866 (Galaxy value status):** a failure status row's `detail` is an MXAccess `MxStatusDetail` code, never an OPC DA quality byte. Bad values now carry specific codes: stopped platform/engine → `BadCommunicationError` (was generic Bad), invalid references → `BadConfigurationError`, type errors → `BadTypeMismatch`, timeout → `BadTimeout`. **OK status rows are now graded by the item's OPC DA quality**: before, an off-scan / Bad / Uncertain attribute with an OK status row was published **Good**; it now arrives Bad/Uncertain. Detail-0 failure rows route on category, not `detected_by` (#872). Live, read-only on VD03: healthy attributes unchanged (Good).
    - **#870:** event monitored-item queues are a ring buffer (SDK-parity tested); no wire change, lower Lock hold at large queues.
  - **CI (#871):** two unit-test races that failed hosted runs 1218–1220 fixed (MeshPsk refresh, credential-lockout burst).
+
+- **2026-11-11 vd03 sister deploys (OtOpcUa itself still `b8b4c18f` there).** mxaccessgw → `2b13564e`, HistorianGateway → `ea9f21c`, ScadaBridge → `424db155`. Consequence: `b8b4c18f`'s Galaxy alarm acks now FAIL against the new gateway (no operator credential; lmxopcua#749) instead of the old silent false success — fixed by deploying OtOpcUa master there (pack: `docs/deploy/vd03-upgrade-b8b4c18f-to-master.md`, preflight #793; needs `Security__ApiKeys__Pepper`, the snapshot-isolation migration, and the SDK 2.0.1 go — #873 clock skew, #874 SDK logging). Galaxy reads/subscribes/host status verified through the new gateway.
@@ -3,3 +3,5 @@
 - **2026-10-13 existing fixes verified and issues closed.** Main `513fa1aa` already includes #35 fail-closed unavailable configured body/SQL redactors (`006202f3`) and #37 Flow Debugger structured/raw validated method inputs (`b5eb08f1`). Fresh full AuditLog project 407 passed/0 failed; FlowDebuggerPageTests 47 passed/0 failed; both terminal exit0. Remote ancestry confirmed; #35/#37 closed with evidence. No source changes/deployment/MES transactions. #36 runtime reset-echo overload is implemented, but QA/prod script port remains tracked; #30 per-site PSK deployment gate remains open.

 - **2026-10-13 #36 runtime regression proof refreshed.** Rebuilt HandshakeResetEchoTests passed all three cases with local fakes, terminal exit0; an earlier no-build attempt matched no tests and is excluded from evidence. Tracker now distinguishes implemented runtime b623fdb0 from remaining QA/prod database-owned script rollout (deployment register row119, scripts13/14/36 and15/16/25/26/37/38). No database writes, deployments or fresh live rig claims.
+
+- **2026-11-11 deployed `424db155` to wonder-app-vd03 (DEV)** (was `0e540291`). Owner-approved WinRM deploy. Migrations 58→64 (`AddNativeAlarmSourceMesReportable`, `PrefixSearchIndexes`, `AddAuditLogHashChain`, `AddConfigGraphRowVersions`, `FlipAuditLogClusteredKey`, `AuditMaintenanceGrants`) applied by script with central + site stopped; #111 DEV sizing: 2,394 rows / 8 MB flip in ~1.5 s. **The plain `dotnet ef migrations script --idempotent` output fails (Msg 207 `ChainSeq`: column added and indexed in one batch)** — the deployed script adds `GO` per guarded block + `XACT_ABORT`; forward/rollback rehearsed on a restored copy of the vd03 DB. Downtime ~50 s; verify OK. Backup `ScadaBridge-backups\ScadaBridge_pre-424db155_20261111T164219.bak`. QA not deployed.