Joseph Doherty
013882262a
v2-ci / build (push) Failing after 44s
v2-ci / unit-tests (tests/Core/ZB.MOM.WW.OtOpcUa.Cluster.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.ControlPlane.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.OpcUaServer.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.Runtime.Tests) (push) Has been skipped
v2-ci / unit-tests (tests/Server/ZB.MOM.WW.OtOpcUa.Security.Tests) (push) Has been skipped
v2-ci / integration (tests/Server/ZB.MOM.WW.OtOpcUa.Host.IntegrationTests) (push) Has been skipped
v2-ci / integration (tests/Server/ZB.MOM.WW.OtOpcUa.OpcUaServer.IntegrationTests) (push) Has been skipped
GalaxyDriver's StreamAlarms feed is session-less and survives an in-place reconnect, so DriverInstanceActor re-subscribed on every Connected re-entry (after dropping its own cached handle without an Unsubscribe — sync teardown). The re-subscribe was additive: _alarmSubscriptions.Add grew the list by one untracked handle per reconnect cycle — a slow unbounded leak. Functionally harmless (the gate is Count>0 and OnAlarmFeedTransition only reads [0], firing once regardless), but it accumulated forever. Fix: SubscribeAlarmsAsync clears the set before adding, collapsing to a single live handle (under the existing _alarmHandlersLock, atomic w.r.t. the fan-out reader). There is exactly one consumer per driver instance (factory-per-actor lifecycle), so replacing the set with the latest handle is faithful. Chosen over making the actor's sync DetachAlarmSource call UnsubscribeAlarmsAsync async/fire-and-forget — disproportionate for a minor leak. Regression test Re_subscribe_collapses_to_a_single_handle_no_accumulation (TDD-verified: FAILS without the Clear — releasing the latest handle leaves the feed open because stale handles remain; PASSES with the fix). Galaxy tests 263 pass / 3 skip; Runtime native-alarm 24 pass. Code-reviewed (approved).