5 Commits

Author	SHA1	Message	Date
Joseph Doherty	513fa1aa16	docs(tests): fix CommentChecker findings across tests/ — 13,392 → 0 (repo-wide scan clean) ... Comment/XML-doc changes only: - add summaries to ~10k test methods, fixtures, fakes and helpers (+ <param> on theories, <returns> on async Task methods, <inheritdoc/> on interface implementations the checker can resolve) - strip ~2.6k project-tracking references (WP*, P*-*, row-NN, Task N, #NN, Component-0NN) from comments, keeping the explanatory text; reword false positives in comments only - real docs on fakes implementing BCL/library interfaces (IDisposable, ILogger, IOptionsMonitor, IAsyncLifetime) - reword the last 5 src/ false positives (CWE-1236, failures-1, year-0001, M365) Only non-comment edits: four one-line nested classes split across lines so members can carry docs. Build 0 errors / 0 warnings.	2026-10-07 15:05:49 -04:00
Joseph Doherty	84b405ff5f	refactor(siteruntime): scope SiteScriptCompileCache to the ScriptCompilationService singleton — close register row 100 ... The compile cache was a `static` class, so its entry table and its Hits/Count counters were one process-global blob every test class in the SiteRuntime assembly wrote into. Row 91 last wave neutered the resulting flakes (per-test GUID keys + one-sided counter bounds), but the shared mutable state itself remained: any test calling Clear() evicted entries other parallel classes had just inserted, and a Clear() from a class outside the serialized collection would degrade the others to recompiles and re-open the row-91 flake class. PREMISE CORRECTION: the register speculated production clears "per-instance or per-deployment script entries" and offered ClearKeys(prefix) as the natural fit. There are NO production callers of Clear() at all — grep of src/ finds only GetOrAdd (ScriptCompilationService.CompileCore). Clear() existed solely so tests could reset the global. A key-scoped API would therefore have been new production surface built for nobody, so the instance-scoped seam is the fix and Clear() is deleted outright rather than migrated. - SiteScriptCompileCache: `internal static class` -> `internal sealed class`; Cache/EvictionLock/_hits/_accessSequence become instance fields. LRU batch eviction, the double-checked sweep and the ConcurrentDictionary.ToArray() snapshot are byte-for-byte the same policy. Clear() removed. - ScriptCompilationService owns one cache. Public ctor (the DI path) builds its own; a new internal ctor takes one for tests. Production N4 sharing is unchanged and now rests on the DI SINGLETON registration — the one service instance is threaded to DeployCompileValidator and to every Instance Actor — so that lifetime is load-bearing and is pinned by a new registration test. - Tests: all three Clear() callers migrated off it. Each test now owns its cache, which lets the assertions get STRONGER — the row-91 workarounds are retired: Hits/Count are exact again (no >= baseline bounds), the per-test GUID key token is gone, and ForeignEntrySlack (512 entries of allowance on the bound) drops to the racing-thread count in the concurrency test. New test SeparateCaches_DoNotShareEntriesOrCounters pins the scoping directly: filling one cache past MaxEntries leaves another's entry, hit count and identity intact. DeploymentWarmThenGateTests additionally asserts Count == 1 now that its counter is private. - The [Collection("SiteScriptCompileCache")] serialization from row 91 is RELAXED (removed from all three classes) — they no longer touch any shared state, so there is nothing left to serialize. - Docs: Component-SiteRuntime.md gains the ownership/singleton note and drops the Clear() reference; DeploymentManagerActor / DeployCompileValidator / ServiceCollectionExtensions comments corrected to say where the cache lives. Build: 0 warnings. SiteRuntime.Tests 643/643, three consecutive full-parallel runs. AuditLog.Tests correlation classes (other ScriptCompilationService consumers) green.	2026-08-17 06:03:58 -04:00
Joseph Doherty	26e3a1b9a6	test(siteruntime): close register row 91 — compile-cache asserts become key-scoped deltas ... SiteScriptCompileCacheTests.GetOrAdd_SameCodeAndGlobals_ComputesOnce asserted Assert.Equal(1, SiteScriptCompileCache.Hits) after a Clear() on what is a process-wide static cache. The [Collection("SiteScriptCompileCache")] attribute serializes this class against ScriptCompilationServiceTests and DeploymentWarmThenGateTests, but NOT against the rest of the assembly: every class that compiles a script — Instance/Script actor tests, deployment tests — goes through the same GetOrAdd in parallel and bumps the same global Hits/Count. Failed ~1 run in 4 under a full parallel solution run, green in isolation. Fixed with the register's row-74 pattern (98c94588): assert the DELTA attributable to this test's OWN keys, never an absolute global value. Two habits carry it. 1. Every test now keys its entries on a per-test-instance guid token (the new Code() helper embeds it as a comment), so no other class in the assembly can collide with or serve them. That makes the factory-call counts and Assert.Same identity checks exact and fully owned — and those are the real claims: "computed once" and "the second lookup returned that instance". 2. The process-global counters are only ever asserted as one-sided bounds (>= baseline + n), since foreign traffic can only add. There is no concurrent Clear() to make a delta go negative: all three classes that call Clear() are in the serialized collection. Four assertions changed shape, and two got stronger rather than weaker. GetOrAdd_SameCode_DifferentGlobals_AreSeparateEntries asserted Count == 2 and Hits == 0 — both only true while nothing else was compiling. "No cross-globals hit" is now asserted where it is observable and ours: the second lookup HAD to compute, the two results are not the same instance, and re-getting either serves its own entry rather than the other globals surface's. Overflow_StaysWithinTheBound gained an eviction probe over its own keys — a bound with foreign slack is not proof a sweep ran; a recompute of an entry we inserted is. Overflow_EvictsOldestBatch_… had Assert.Equal(hitsBefore + 1, Hits), the same absolute-delta shape, now a lower bound alongside the sharp Assert.Same. DeploymentWarmThenGateTests carried the identical latent shape one line before its own delta assertion — Assert.Equal(0, Hits) immediately after Clear() — and is converted to a baseline snapshot too. SiteRuntime.Tests: 633/633 green, twice, at full parallelism (43 s, 42 s).	2026-08-17 05:27:22 -04:00
Joseph Doherty	7a7d345b89	test: replace wall-clock sleeps used as synchronization — register row 40 ... Six sleeps across four test files stood in for an observable edge. Each preceded an ABSENCE assertion (or "settled" before one), so they failed toward false-pass rather than flake: the assertion could not distinguish "the mechanism ran and correctly stayed quiet" from "the mechanism had not run yet". ScriptDeadlineAtEnqueueTests (two sleeps, the worst offender) - :105 Thread.Sleep(2s) — now two explicit edges: the run must be observably QUEUED (scheduler.QueueDepth >= 1, never checked before), then the wait polls until the 1 s budget has elapsed, bailing early if the run leaves the queue, and asserts it is STILL queued afterwards. The test now proves the design claim it was named for — queue wait burns the run's budget — instead of assuming it. - :128 Thread.Sleep(2s) + Assert.Equal(0, DetachedThreadCount) — replaced by a positive control: a second script that genuinely wedges a worker, on the same scheduler, same 1 s timeout + 1 s grace, armed strictly later. Its stuck report is the edge; once it lands, every watchdog armed at or before it has provably finished its grace delay. The absence is then asserted per script name, and the detach counter is pinned at 1 (the wedged run) rather than 0 — which a counter that never moves also satisfied. DeploymentWarmThenGateTests (:117 plus two sibling Task.Delay(500) startup waits) - The manager calls SetInstanceCounts unconditionally when its startup config load completes, so a report counter on the test collector is the startup edge. The empty-site zero is now the manager's own observation instead of an untouched field. SiteAlarmLiveCacheServiceTests (:195, :216) - Both sampled IsLive once after a fixed sleep. Now they poll continuously across three linger windows on a new teardown observable (the mock client counts subscription cancellations), so a stop at any instant inside the window is caught, and each closes with a positive control proving that counter moves. DataConnectionActorTests (:435) - A Task.Delay(200) "settle" after an AwaitCondition on a connect counter. The counter only proves ConnectAsync was CALLED; the actor is still Connecting until it processes the piped result. Now waits for the Connected health publication that BecomeConnected emits, so the subscribe under test provably runs against Connected rather than being silently stashed. (The stash path keeps its own coverage in WP6_ConnectingState_StashesSubscribeRequests.) Negative controls (product broken in the working tree, old vs new test compared): - Stuck-script watchdog disabled entirely: OLD test passed 2/2, NEW test failed. The whole watchdog could be deleted and the old assertions were satisfied. - Startup reporting a phantom instance count and taking longer than 500 ms: OLD passed 2/2, NEW failed (expected 0, actual 1). - Linger cancellation disabled + the remaining-viewer guard dropped, so the stream is torn down under a live viewer while IsLive keeps reporting true: Resubscribe_Within_Linger OLD passed 2/2, NEW failed. (Last_Viewer_Leaving caught this particular break in the old form too, via a later assertion — its strengthening is the teardown observable and the positive control, not a false-pass fix.) - DataConnectionActorTests :435 has no false-pass demo: the sleep guarded no assertion there, and the change is determinism plus proving the claimed state. Also fixes a latent race these timing changes exposed in InstanceActorChildAttributeRaceTests: it resolved child actors single-shot immediately after construction, but ResolveOne throws until the child's cell is published on the parent AND the cell's Actor property stays null until the child's constructor has run on its own mailbox thread. Neither is ordered against the test thread, so it failed both ways under full-suite load (~1 run in 6 once the sleeps above stopped padding the schedule; 14/14 green on the unmodified tree, so it was latent, not new). Resolution now retries to a bounded deadline; the assertion is unchanged. Verification: SiteRuntime.Tests 8/8 green (605 tests), Communication.Tests 3/3 (717), DataConnectionLayer.Tests 3/3 (319). Test-only change — no src/ modifications.	2026-08-15 17:06:51 -04:00
Joseph Doherty	c4fc1f8ecd	perf(runtime): split trigger evals from the blocking pool; bounded, deadline-aware execution	2026-08-14 22:36:15 -04:00