dohertj2/mxaccessgw
1
0
Fork 0
Code Issues 7 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Add opt-in managed GUID alarm-ack path #160

Closed
dohertj2 wants to merge 0 commits from feat/managed-guid-alarm-ack into main
pull from: feat/managed-guid-alarm-ack
merge into: dohertj2:main
Conversation 1 Commits - Files Changed -
dohertj2 commented 2026-10-18 13:00:22 -04:00
Owner
Copy Link
Copy Source

Adds a managed acknowledge path over AVEVA's modern alarm client so GUID acks carry full operator identity (domain + full name) and work on builds where the wnwrap COM AlarmAckByGUID is E_NOTIMPL.

Default off — opt in with MXGATEWAY_USE_MANAGED_ALARM_ACK=1; wnwrap behavior is unchanged otherwise.

Changes

  • AaManagedAlarmAckConsumer — reflection wrapper over aaAlarmManagedClient.AlarmClient (InitializeConsumer/RegisterConsumer/Subscribe/AlarmAckByGUID). EnvGatedFactory degrades to the wnwrap path if the DLL can't load, so alarm reads never break.
  • IManagedAlarmAckClient seam. AlarmDispatcher takes an optional client and routes GUID acks to it (subscribing + disposing it alongside the reader).
  • AlarmCommandHandler gains an optional managedAckFactory; WorkerPipeSession wires AaManagedAlarmAckConsumer.EnvGatedFactory at the production sites.
  • WnalNativeAckConsumer — confirmed native alarmlst.dll WNAL submit layer (WNALalarmReqSetText/WNALUserRequest/WNALUserRequestEx + lpAlmAck layout). List acquisition is intentionally not hand-rolled: the alarm-record layout and selection semantics are provider-defined and not recoverable from alarmlst.dll, so inferring them would risk acking the wrong alarm.
  • AlarmManagedGuidAckLiveSmokeTests — skip-gated live smoke that pulls a real (non-degraded) alarm GUID and asserts the ack applies (Acknowledge transition / acked snapshot), not merely rc=0.

By-name acks stay on wnwrap (AlarmClient has no AlarmAckByName).

Validation

  • x86 Worker + Worker.Tests build clean (0 warnings, TreatWarningsAsErrors).
  • 200 alarm unit tests pass (6 live-rig skips).

Notes / runtime confirmation still needed

  • RegisterConsumer's trailing bool is passed false (meaning unconfirmed).
  • Whether Subscribe is strictly required before AlarmAckByGUID.
  • For a secured (MxSecurityOperate) alarm the ack must run under an authenticated operator; rc=0 means accepted, not applied. The new smoke test is the harness for this.

Grounded in static RE of alarmlst.dll, aaAlarmManagedClient.dll, and alarmmgr.exe.

🤖 Generated with Claude Code

Adds a managed acknowledge path over AVEVA's modern alarm client so GUID acks carry full operator identity (domain + full name) and work on builds where the wnwrap COM `AlarmAckByGUID` is `E_NOTIMPL`. **Default off** — opt in with `MXGATEWAY_USE_MANAGED_ALARM_ACK=1`; wnwrap behavior is unchanged otherwise. ## Changes - **`AaManagedAlarmAckConsumer`** — reflection wrapper over `aaAlarmManagedClient.AlarmClient` (`InitializeConsumer`/`RegisterConsumer`/`Subscribe`/`AlarmAckByGUID`). `EnvGatedFactory` degrades to the wnwrap path if the DLL can't load, so alarm reads never break. - **`IManagedAlarmAckClient`** seam. `AlarmDispatcher` takes an optional client and routes GUID acks to it (subscribing + disposing it alongside the reader). - **`AlarmCommandHandler`** gains an optional `managedAckFactory`; **`WorkerPipeSession`** wires `AaManagedAlarmAckConsumer.EnvGatedFactory` at the production sites. - **`WnalNativeAckConsumer`** — confirmed native `alarmlst.dll` WNAL submit layer (`WNALalarmReqSetText`/`WNALUserRequest`/`WNALUserRequestEx` + `lpAlmAck` layout). List acquisition is intentionally **not** hand-rolled: the alarm-record layout and selection semantics are provider-defined and not recoverable from `alarmlst.dll`, so inferring them would risk acking the wrong alarm. - **`AlarmManagedGuidAckLiveSmokeTests`** — skip-gated live smoke that pulls a real (non-degraded) alarm GUID and asserts the ack **applies** (Acknowledge transition / acked snapshot), not merely `rc=0`. By-name acks stay on wnwrap (`AlarmClient` has no `AlarmAckByName`). ## Validation - x86 Worker + Worker.Tests build clean (0 warnings, `TreatWarningsAsErrors`). - 200 alarm unit tests pass (6 live-rig skips). ## Notes / runtime confirmation still needed - `RegisterConsumer`'s trailing `bool` is passed `false` (meaning unconfirmed). - Whether `Subscribe` is strictly required before `AlarmAckByGUID`. - For a secured (`MxSecurityOperate`) alarm the ack must run under an authenticated operator; `rc=0` means accepted, not applied. The new smoke test is the harness for this. Grounded in static RE of `alarmlst.dll`, `aaAlarmManagedClient.dll`, and `alarmmgr.exe`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
dohertj2 added 1 commit 2026-10-18 13:00:23 -04:00
feat(worker): add opt-in managed GUID alarm-ack path
ci / nightly-windev (push) Has been skipped
Details
ci / windows-x86 (push) Successful in 1m19s
Details
ci / java (push) Successful in 2m8s
Details
ci / portable (push) Failing after 2m23s
Details
ci / nightly-windev (pull_request) Has been skipped
Details
ci / windows-x86 (pull_request) Successful in 1m18s
Details
ci / java (pull_request) Successful in 2m3s
Details
ci / portable (pull_request) Failing after 2m17s
Details
6affbd57ea 
Adds a managed acknowledge path over AVEVA's modern alarm client so GUID
acks carry full operator identity (domain + full name) and work on builds
where the wnwrap COM AlarmAckByGUID is E_NOTIMPL. Default off; opt in with
MXGATEWAY_USE_MANAGED_ALARM_ACK=1 (wnwrap behavior unchanged otherwise).

- AaManagedAlarmAckConsumer: reflection wrapper over
  aaAlarmManagedClient.AlarmClient (InitializeConsumer/RegisterConsumer/
  Subscribe/AlarmAckByGUID); EnvGatedFactory degrades to null (wnwrap) if the
  DLL can't load, so alarm reads never break.
- IManagedAlarmAckClient seam. AlarmDispatcher takes an optional client and
  routes GUID acks to it (subscribing + disposing it alongside the reader).
- AlarmCommandHandler gains an optional managedAckFactory; WorkerPipeSession
  wires AaManagedAlarmAckConsumer.EnvGatedFactory at the production sites.
- WnalNativeAckConsumer: confirmed native alarmlst.dll WNAL submit layer
  (WNALalarmReqSetText / WNALUserRequest / WNALUserRequestEx + lpAlmAck
  layout). List acquisition is intentionally not hand-rolled: the alarm-record
  layout and selection semantics are provider-defined and not recoverable from
  alarmlst.dll, so inferring them risks acking the wrong alarm.
- AlarmManagedGuidAckLiveSmokeTests: skip-gated live smoke that pulls a real
  (non-degraded) alarm GUID and asserts the ack APPLIES (Acknowledge
  transition / acked snapshot), not merely rc=0.

By-name acks stay on wnwrap (AlarmClient has no AlarmAckByName). Grounded in
static RE of alarmlst.dll, aaAlarmManagedClient.dll and alarmmgr.exe.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dohertj2 added 1 commit 2026-10-18 13:11:05 -04:00
Keep subtag acks and alarm reads safe on the managed ack path
ci / nightly-windev (push) Has been skipped
Details
ci / windows-x86 (pull_request) Successful in 2m0s
Details
ci / nightly-windev (pull_request) Has been skipped
Details
ci / java (pull_request) Successful in 2m16s
Details
ci / java (push) Successful in 2m19s
Details
ci / portable (push) Failing after 2m31s
Details
ci / portable (pull_request) Failing after 2m36s
Details
ci / windows-x86 (push) Successful in 3m11s
Details
6f4c7c3bf1 
Review fixes for the opt-in managed GUID ack:

- Subtag-mode GUID acks (forced subtag, or failover on the standby) stay on
  the consumer; their GUIDs are synthetic and only the subtag consumer can
  resolve them. Forced-subtag sessions no longer build a managed client.
- A failed managed Initialize/Register/Subscribe drops back to the wnwrap
  ack path instead of failing the alarm subscription.
- Drop stale crefs to a nonexistent Unverified member in
  WnalNativeAckConsumer.
- Unit tests for routing, fallback, and disposal; document
  MXGATEWAY_USE_MANAGED_ALARM_ACK.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dohertj2 commented 2026-10-18 13:13:51 -04:00
Author
Owner
Copy Link
Copy Source

Merged into main as 6c82de55c6 (with review fix commit 6f4c7c3: subtag-mode acks stay on the subtag consumer, managed lifecycle failure falls back to wnwrap, stale crefs removed, tests + docs). x86 Worker.Tests on windev: 533 passed, 0 failed.

Merged into main as 6c82de55c6a700c9da69015f9084c69b4429eb42 (with review fix commit 6f4c7c3: subtag-mode acks stay on the subtag consumer, managed lifecycle failure falls back to wnwrap, stale crefs removed, tests + docs). x86 Worker.Tests on windev: 533 passed, 0 failed.
dohertj2 closed this pull request 2026-10-18 13:13:51 -04:00
Some checks are pending
ci / nightly-windev (push) Has been skipped
Details
ci / windows-x86 (pull_request) Successful in 2m0s
Details
ci / nightly-windev (pull_request) Has been skipped
Details
ci / java (pull_request) Successful in 2m16s
Details
ci / java (push) Successful in 2m19s
Details
ci / portable (push) Failing after 2m31s
Details
ci / portable (pull_request) Failing after 2m36s
Details
ci / windows-x86 (push) Successful in 3m11s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
area:auth
Authentication and authorization
 area:client-dotnet
.NET client library
 area:client-go
Go client library
 area:client-java
Java client library
 area:client-python
Python client library
 area:client-rust
Rust client library
 area:contracts
Protocol and generated contract work
 area:dashboard
Blazor dashboard work
 area:docs
Documentation
 area:gateway
Gateway server work
 area:tests
Automated and live tests
 area:worker
MXAccess worker process work
 blocked
Blocked by dependency
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 type:docs
Documentation work
 type:feature
Feature implementation
 type:infra
Infrastructure and scaffolding
 type:test
Test work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/mxaccessgw#160
Delete Branch "feat/managed-guid-alarm-ack"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?