docs: QA central pair relays standby inbound API calls (StandbyForwardPeerEndpoints)

2026-10-22 16:59:07 -04:00
parent 4bc124d73e
commit 3e1435dfac
2 changed files with 20 additions and 2 deletions
@@ -130,7 +130,25 @@ Backups: `E:\psrem-stage\3808b49f\_envbak-ScadaBridge-Central-pre-sharedstores-<

 The `zbauth` and `zbsecrets` rows can stay; the SQLite path never reads them.

+## Follow-up 2: inbound API standby relay (16:57)
+
+`ScadaBridge:InboundApi:StandbyForwardPeerEndpoints` was added to each box's `appsettings.Central.json`:
+- vq03 → `["http://10.220.158.3:8085"]`
+- vq04 → `["http://10.220.158.2:8085"]`
+
+`StandbyForwardTimeout` stays at its 60 s default, which is above QA's longest method timeout (`MesMoveIn` 46 s). The relay signature uses `ApiKeyPepper`, which is identical on both centrals.
+
+**Rolling restart, standby first:**
+1. vq04: stop 16:57:09, service process exited, file pushed over SMB, ready 16:57:28.
+2. Waited for 2 members / 0 unreachable.
+3. vq03: stop 16:57:33, ready 16:57:51.
+
+The cluster never dropped below one serving central. **vq04 is now the active node** (failover on vq03's restart); nothing depends on which node is active.
+
+Backups: `E:\ApiInstall\ScadaBridge\_appsettings.Central.json.pre-relay-<ts>` on each box.
+
+**Verified:** a bogus-key inbound call answers **401 `UNAUTHORIZED` on both nodes**. The standby (vq03) used to answer 503 `STANDBY_NODE`; it now relays to the active peer, and the peer's answer is replayed.
+
 ## Outstanding

- **Standby relay:** QA still has no `ScadaBridge:InboundApi:StandbyForwardPeerEndpoints`, so an inbound call sent to the standby answers 503 `STANDBY_NODE` instead of being relayed to the active node.
 - **Housekeeping after soak:** delete the `*.imported` key files; also the older `app.bak.*`, `cli.bak.*`, `_appsettings-keep-*` and `E:\psrem-stage\*` folders on both boxes.