docs: record gateway-level live verification of AckMsg-as-operator acks

Claude-Session: https://claude.ai/code/session_016J6isfcgqy4SB2RK3ZvFvT
2026-10-19 20:07:36 -04:00
parent e7f56622c1
commit 3e988ede88
1 changed files with 23 additions and 0 deletions
@@ -492,3 +492,26 @@ The gateway acknowledges by authenticating the operator and writing `AckMsg`
 (`docs/DesignDecisions.md`, "Alarm acknowledgement writes AckMsg as the
 authenticated operator"). The managed ack consumer and the second wnwrap ack
 consumer were removed.
 ### Gateway-level verification
 The same result holds end to end through the gateway. With the feature build deployed on
 the windev rig and `TestAlarm001` raised, an `AcknowledgeAlarm` RPC for
 `Galaxy!TestArea.TestMachine_001.TestAlarm001` with `operator_user=Administrator` and an
 empty password returned `PROTOCOL_STATUS_CODE_OK`, `hresult` 0. `.Acked` turned True,
 `.AckMsg` held the comment, and the Historian logged the `ACK_ALM` row with
 `Operator=Administrator`, `DomainName=ArchestrA`, `UserFullName=Administrator`,
 `OperatorNode=MxGateway` (the default `AckClientName`), and `Description` = the comment.
 A wrong password, or a user Galaxy security does not know, makes `AuthenticateUser`
 throw `ArgumentException` (`E_INVALIDARG`, 0x80070057) rather than a `COMException`.
 That is why the writer classifies interop failures by HRESULT across exception types.
 Such an ack returns `PROTOCOL_STATUS_CODE_MXACCESS_FAILURE`, the alarm stays unacked,
 the Historian gains no ack row, and the password string does not appear in the gateway
 log, `stdout.log`, or `stderr.log`. A non-Galaxy provider reference returns
 `PROTOCOL_STATUS_CODE_INVALID_REQUEST` with `hresult` -1, and an empty `operator_user`
 returns gRPC `InvalidArgument`.
 The GUID arm of the ack command was not driven live. The public alarm RPCs expose only
 the full reference, so clients reach the by-name arm; worker unit tests cover the GUID
 arm.