fix(review): remediate re-review findings — DCL-029/InboundAPI-031/SiteRuntime-032/StoreAndForward-028 + Low doc/test

Fixes the 8 findings from the 2026-06-24 re-review (commit c42bb485), with a regression test per Medium finding: - DataConnectionLayer-029 (Med): HandleAlarmSubscribeCompleted now mirrors the tag-path re-check — if a feed is already stored for the source, release the redundant just-created subscription instead of overwriting + leaking the first one (the double-subscribe window DCL-023 reopened). +regression test. - InboundAPI-031 (Med): remove WaitForAttribute's local 5s grace backstop (tighter than the CommunicationService Ask's timeout+IntegrationTimeout round-trip budget, so a slow-but-valid timed-out 'false' got cancelled into a 500). Link only the client-abort + explicit caller tokens; the lower layer owns the backstop. +test. - SiteRuntime-032 (Med): derive the deployed count from an authoritative set of deployed config names (HashSet) instead of a map-presence-gated int, so deleting a DISABLED instance decrements correctly (SiteRuntime-029's gate leaked it). +deploy->disable->delete regression test. - StoreAndForward-028 (Med): reset _bufferedCount in StopAsync alongside the register-guard so a same-instance Stop->Start re-seeds from a clean base (no ~2N gauge double-count). +restart regression test. - AuditLog-017 (Low): test the OnIngestAsync scope-resolution guard (actor survives, replies empty, counts the failure) — no longer unpinned. - CentralUI-037 / ScriptAnalysis-009 / SiteRuntime-033 (Low): doc-comment + spec fixes (Database-throws in the inbound sandbox; baseReferences param wording; native-alarm cap return-to-normal + per-condition NativeAlarmDropped eviction). Targeted suites green: SiteRuntime 5, StoreAndForward 6, InboundAPI 31, DataConnectionLayer 10, AuditLog 5, ScriptAnalysis 40, CentralUI ScriptAnalysis 52.
2026-06-24 09:39:14 -04:00
parent c42bb48585
commit 9ab1c00265
12 changed files with 320 additions and 34 deletions
@@ -306,4 +306,84 @@ public class DataConnectionActorAlarmTests : TestKit
        await alarmable.Received(2).SubscribeAlarmsAsync(
            "Tank01", Arg.Any<string?>(), Arg.Any<AlarmTransitionCallback>(), Arg.Any<CancellationToken>());
    }
+
+    // ── DataConnectionLayer-029: a re-subscribe during an orphaned in-flight subscribe
+    //    must not leak a duplicate adapter feed ──
+
+    [Fact]
+    public async Task DCL029_ResubscribeDuringOrphanedInFlightSubscribe_ReleasesDuplicateFeed_NoLeak()
+    {
+        // Regression test for DataConnectionLayer-029. The DCL-023 fix clears the in-flight
+        // marker on unsubscribe, which reopens a double-subscribe window: unsubscribe (last
+        // subscriber, subId not stored yet) → a fresh subscribe for the SAME source sees
+        // neither a stored id nor an in-flight marker, so it issues a SECOND adapter feed →
+        // both completions fire. The DCL-023 orphan guard does NOT trigger on either
+        // completion (the re-subscribe re-added the subscriber), so the alarm completion
+        // handler used to OVERWRITE _alarmSubscriptionIds with the second id — leaking the
+        // first feed (never unsubscribed, kept streaming). After DCL-029 the handler mirrors
+        // the tag-path re-check: when a feed is already stored, the redundant completion
+        // releases its just-created feed instead of overwriting + leaking.
+        var sub1Started = new TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);
+        var sub1Release = new TaskCompletionSource<string>(TaskCreationOptions.RunContinuationsAsynchronously);
+        var sub2Started = new TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);
+        var sub2Release = new TaskCompletionSource<string>(TaskCreationOptions.RunContinuationsAsynchronously);
+
+        var adapter = Substitute.For<IDataConnection, IAlarmSubscribableConnection>();
+        adapter.ConnectAsync(Arg.Any<IDictionary<string, string>>(), Arg.Any<CancellationToken>())
+            .Returns(Task.CompletedTask);
+        var alarmable = (IAlarmSubscribableConnection)adapter;
+
+        var calls = 0;
+        alarmable.SubscribeAlarmsAsync(Arg.Any<string>(), Arg.Any<string?>(),
+                Arg.Any<AlarmTransitionCallback>(), Arg.Any<CancellationToken>())
+            .Returns(_ =>
+            {
+                if (Interlocked.Increment(ref calls) == 1)
+                {
+                    sub1Started.TrySetResult();
+                    return sub1Release.Task;
+                }
+                sub2Started.TrySetResult();
+                return sub2Release.Task;
+            });
+        alarmable.UnsubscribeAlarmsAsync(Arg.Any<string>(), Arg.Any<CancellationToken>())
+            .Returns(Task.CompletedTask);
+
+        var actor = Sys.ActorOf(Props.Create(() => new DataConnectionActor(
+            "conn", adapter, _options, _health, _factory, "OpcUa")));
+
+        // (1) Subscribe A — adapter subscribe #1 parks, in-flight={Tank01}.
+        actor.Tell(new SubscribeAlarmsRequest("c1", "instA", "conn", "Tank01", null, DateTimeOffset.UtcNow));
+        await sub1Started.Task.WaitAsync(TimeSpan.FromSeconds(5));
+
+        // (2) Last subscriber unsubscribes while subscribe #1 is in flight — clears the
+        // in-flight marker (DCL-023); subId#1 is not stored yet so no teardown happens.
+        actor.Tell(new UnsubscribeAlarmsRequest("unsub-c1", "instA", "conn", "Tank01", DateTimeOffset.UtcNow));
+        await Task.Delay(150);
+
+        // (3) Fresh subscribe for the SAME source before #1 completes — neither a stored id
+        // nor an in-flight marker exists, so the actor issues a SECOND adapter subscribe.
+        actor.Tell(new SubscribeAlarmsRequest("c2", "instB", "conn", "Tank01", null, DateTimeOffset.UtcNow));
+        await sub2Started.Task.WaitAsync(TimeSpan.FromSeconds(5));
+
+        // (4) Complete subscribe #1 → a subscriber exists again (B re-added), so the orphan
+        // guard does NOT fire and subId#1 is stored as the live feed.
+        sub1Release.SetResult("alarm-sub-1");
+        await Task.Delay(150);
+
+        // (5) Complete subscribe #2 → a feed is already stored, so this redundant completion
+        // releases its just-created feed (#2) instead of overwriting + leaking subId#1.
+        sub2Release.SetResult("alarm-sub-2");
+        await Task.Delay(300);
+
+        // The duplicate feed (#2) is released exactly once; the first feed (#1) is retained.
+        await alarmable.Received(1).UnsubscribeAlarmsAsync("alarm-sub-2", Arg.Any<CancellationToken>());
+        await alarmable.DidNotReceive().UnsubscribeAlarmsAsync("alarm-sub-1", Arg.Any<CancellationToken>());
+
+        // The retained feed (#1) is what a later unsubscribe tears down — proving subId#1,
+        // not the duplicate, is the id _alarmSubscriptionIds actually tracks (no leak).
+        actor.Tell(new UnsubscribeAlarmsRequest("unsub-c2", "instB", "conn", "Tank01", DateTimeOffset.UtcNow));
+        await Task.Delay(200);
+        await alarmable.Received(1).UnsubscribeAlarmsAsync("alarm-sub-1", Arg.Any<CancellationToken>());
+    }
 }