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

docs(otopcua-history): wire ServiceLevel correct on SDK 2 (#884 claim, #885 startup 0); vd03 still 255 until redeployed

Browse Source 
Claude-Session: https://claude.ai/code/session_01GT67ACmpMR7b9LGRPLijMi
This commit is contained in:
Joseph Doherty
2026-11-12 11:21:12 -05:00
parent d5de462f19
commit da4cb92713
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/sister-project-history/otopcua.md
+8
View File
@@ -491,3 +491,11 @@ its Galaxy acks fail against mxaccessgw `2b13564e` did not apply to this box's d
- **The fix:** `LegacyRsaUserNameIdentityTokenHandler`, plugged in through `UserIdentity(IUserIdentityTokenHandler)` and exposed as `OpcUaUserIdentityFactory.UserName`, always sends the legacy format under an RSA policy. That is what SDK 2 already sends for 64 bytes or less and what 1.5 clients always send. An SDK 2 server reads both formats. Client.Shared now references `Driver.OpcUaClient.Session`.
- **Cross-version matrix (#782):** it now uses the 65-character key shape. The old 55-character `otua_matrix_` key had hidden the bug. The matrix adds a wrong-key case and an SDK-default negative-control case (`2ad72130`). Evidence for the fixed and mutated runs is in `e5b26f37`. The same run exposed #888: the matrix fixture's UNS folder has had no ACL placement since #808, so UNS cases are denied against master for every client.
- **ScadaBridge consumer impact: none.** ScadaBridge is an SDK 1.5 client and always sent the legacy format. Generic SDK 2 tools that use the SDK's default handler are still refused by SDK 1.5 servers when the key is 65 characters.
- **2026-11-12 master `f66b9dae` + `5e3fb422` (#884) and `3fff439b` (#885), not deployed: wire `Server.ServiceLevel` is now correct on SDK 2.0.1.**
- **The bug (#884):** SDK 2.0.1 recomputes ServiceLevel from session headroom on every session create/close and overwrites any value ≥ 200 with 255 unless a provider claims it. `SdkServiceLevelPublisher` never claimed it, so both pair nodes read 255, and a Stale 200 also read 255.
- **The fix (#884):** the publisher now claims the value through `IServerServiceLevelControl.ClaimServiceLevelControl()` and writes through the SDK's writer.
- **#885:** the server now starts at 0 (`OtOpcUaSdkServer.StartupServiceLevel`, the Down/Detached tier) instead of the SDK's 255. A restarting pair node no longer out-ranks the Primary for the ~10 s before its first redundancy snapshot.
- **Rig check (docker-dev, `3fff439b`):** all three pairs read 250/240. A rejoining node reads 0 → 240 and never goes above 240. Record: lmxopcua#801 comment 11855.
- **ScadaBridge consumer impact: none.** Its OPC UA failover is endpoint-level and doesn't read ServiceLevel. Generic clients that pick the highest ServiceLevel now get Primary preference back.
- **Deployed boxes:** DEV vd03 (`5fb4b4db`, SDK 2.0.1, single node) still advertises 255 instead of 250, and would show 255 for a Stale 200, until it's redeployed with master. QA vq03/vq04 (SDK 1.5, `b8b4c18f`) are unaffected. This was the blocker for the QA SDK 2 rollout under #801.