test(coverage): close Theme 8 — 13 test-coverage findings, +35 tests

13 well-bounded test-coverage gaps closed across 11 test projects.
Net +35 regression tests; no production code changes except the
SiteEventLogger src reference unchanged (W3 redacted only test code).

Test additions:
- CLI-022: CommandTreeTests pinned-count assertion bumped 14→16 and
  3 InlineData rows added for the audit + bundle command groups.
- Commons-020: new TransportRecordsTests covers BundleManifest /
  ExportSelection / ImportPreview / ImportResolution / ImportResult —
  ctor + System.Text.Json round-trip + record-equality (14 tests).
- CD-024: SPLIT-RANGE failure-continuation now under
  EnsureLookahead_SecondSplitThrows_LoopAborts_FirstBoundaryStillCommitted
  (Skippable MS-SQL fixture); production-shape rowversion delete
  asserted by DeleteDeploymentRecord_CurrentRowVersion_StubAttachPath_DeleteSucceeds.
- CentralUI-033: new QueryStringDrillInTests with 4 bUnit cases for
  Transport + SiteCalls drill-in / query-string handling.
- DM-024: probe actors (ReconcileProbeActor, SerializationProbeActor,
  ArtifactProbeActor) refactored from static fields to per-test instances
  (Interlocked on counter) — all 31 callers updated; no production
  changes required.
- HM-022: real-time PeriodicTimer test flake fixed by replacing
  fixed-budget Task.Delay with a RunLoopUntil poll-until-condition
  helper (5s/25ms). Production loop untouched.
- InboundAPI-023: new EndpointExtensionsTests covers the
  POST /api/{methodName} composition wiring via TestServer (7 cases:
  happy path, missing key 401, unknown method 403, invalid JSON 400,
  missing param 400, script-throws 500 sanitised, AuditActorItemKey
  stash invariant).
- MgmtSvc-021: 6 new ManagementActorTests cover the Transport bundle
  handlers (role gate for Export/Preview/Import, unknown-name
  ManagementCommandException, blocker-rejection, dedupe last-write-wins).
- SCA-006: SiteCallQueryRequest_StuckOnly_CursorAtNonStuckBoundary_SkipsToNextStuckRow
  pins the missing boundary case.
- SEL-023: stress-test `bool stop` promoted to `volatile bool` for
  cross-thread visibility under release/JIT.

Verify-only resolutions:
- NS-024: closed by NS-019 (commit ac96b83 deletion of
  NotificationDeliveryService + its test file). No edits needed.
- NotifOutbox-008: FallbackMaxRetries/FallbackRetryDelay are private
  forward-compat constants returned only when no SMTP-config row exists
  (in which case EmailNotificationDeliveryAdapter returns Permanent,
  bypassing the values entirely). Marked Resolved with note.
- Transport-010: Overwrite child-collection sync covered by the T-001/
  T-002 tests added in commit e3ca9af; per-IP throttle by
  BundleUnlockRateLimiterTests; failed-session retention by
  BundleSessionStoreTests; T-009 closed structurally via AsyncLocal.
  Marked Resolved by reference.

Build clean; all 11 affected test suites green. README regenerated:
33 open (was 46).
This commit is contained in:
Joseph Doherty
2026-05-28 08:21:03 -04:00
parent 46cb6965ac
commit d190345ef0
26 changed files with 1725 additions and 155 deletions
@@ -29,13 +29,53 @@ public class CentralHealthReportLoopTests
public SiteHealthState? GetSiteState(string siteId) => null;
}
private static async Task RunLoopBriefly(CentralHealthReportLoop loop, int runForMs)
/// <summary>
/// HealthMonitoring-022 de-flake: <see cref="CentralHealthReportLoop"/>'s
/// internal cadence is a real <see cref="PeriodicTimer"/>, so the loop is
/// timing-sensitive. We can't drive a virtual clock (PeriodicTimer doesn't
/// consume <see cref="TimeProvider"/>) without refactoring the production
/// loop, so we keep wall-clock waits but use a *generous* budget: a 5 s
/// outer cancellation cap with a poll-until-condition wait, instead of a
/// fixed <see cref="Task.Delay"/> that fails fast on a slow CI runner. The
/// loop's <c>ReportInterval</c> is set to 50 ms in each test, so under
/// normal conditions the condition is met almost immediately; under heavy
/// CI load the poll loop tolerates the slow tick instead of asserting on a
/// timed-out empty list.
/// </summary>
private static async Task RunLoopUntil(
CentralHealthReportLoop loop,
Func<bool> condition,
TimeSpan? maxWait = null)
{
using var cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(runForMs + 100));
var deadline = maxWait ?? TimeSpan.FromSeconds(5);
using var cts = new CancellationTokenSource(deadline + TimeSpan.FromSeconds(1));
try
{
await loop.StartAsync(cts.Token);
await Task.Delay(runForMs, CancellationToken.None);
var sw = System.Diagnostics.Stopwatch.StartNew();
while (sw.Elapsed < deadline && !condition())
{
await Task.Delay(25, CancellationToken.None);
}
await loop.StopAsync(CancellationToken.None);
}
catch (OperationCanceledException) { }
}
/// <summary>
/// Used by tests that need the loop to run for a bounded period without
/// waiting on a specific condition (e.g. asserting <i>no</i> reports were
/// produced). The wait is generous (1 s default) — see
/// <see cref="RunLoopUntil"/> for the rationale.
/// </summary>
private static async Task RunLoopBriefly(CentralHealthReportLoop loop, int runForMs)
{
var totalMs = Math.Max(runForMs, 1000);
using var cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(totalMs + 1000));
try
{
await loop.StartAsync(cts.Token);
await Task.Delay(totalMs, CancellationToken.None);
await loop.StopAsync(CancellationToken.None);
}
catch (OperationCanceledException) { }
@@ -56,7 +96,9 @@ public class CentralHealthReportLoopTests
collector, aggregator, clusterNodes, options,
NullLogger<CentralHealthReportLoop>.Instance);
await RunLoopBriefly(loop, 250);
// HealthMonitoring-022: wait up to 5 s for at least one report to fire
// rather than fixed-budget Task.Delay; tolerates slow CI runners.
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 1);
Assert.NotEmpty(aggregator.Processed);
Assert.All(aggregator.Processed,
@@ -98,7 +140,10 @@ public class CentralHealthReportLoopTests
collector, aggregator, clusterNodes, options,
NullLogger<CentralHealthReportLoop>.Instance);
await RunLoopBriefly(loop, 300);
// HealthMonitoring-022: wait up to 5 s for at least 2 reports rather
// than a fixed 300 ms window that could miss the second tick on a
// slow CI runner; the assertion below proves the sequence is monotonic.
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 2);
Assert.True(aggregator.Processed.Count >= 2,
$"Expected at least 2 reports, got {aggregator.Processed.Count}");
@@ -170,7 +215,10 @@ public class CentralHealthReportLoopTests
collector, aggregator, clusterNodes, options,
NullLogger<CentralHealthReportLoop>.Instance);
await RunLoopBriefly(loop, 450);
// HealthMonitoring-022: the first ProcessReport call throws (counters
// get restored), the second succeeds. Wait up to 5 s for that second
// (successful) call rather than a fixed 450 ms budget.
await RunLoopUntil(loop, () => aggregator.Processed.Count >= 1);
// First call threw, later succeeded — the first successful report
// must carry the previously-failed interval's accumulated counts.