De-flake ParallelTestActorDeadlockSpec: wait for the actor, dilate the budgets

[Aaronontheweb]

Summary

De-flakes ParallelTestActorDeadlockSpec, which timed out on the Windows unit-test lane for #8594 (Timeout 00:00:05 while waiting for a message of type System.String, one of sixteen TestKits). This is the fourth PR against this spec; #7974, #8016 and #8023 each raised a budget or lowered the concurrency and the failure kept returning.

The spec keeps its 16 Task.Run bodies on ThreadPool threads. That is deliberate: it is what Akka.Hosting.TestKit does (the TestKit is built inside a StartActors callback on a host-startup continuation), and it is the condition the spec exists to guard. An earlier revision of this PR moved the bodies to dedicated threads, which made the numbers pretty and would have hidden a real regression class. Reverted.

Root cause of the flake

Building a TestKit blocks its caller more than once: LoggingBus.StartDefaultLoggers waits up to akka.logger-startup-timeout, and TestKitBase waits for the TestActor's PreStart. Every one of those waits is for work that runs on the same CLR ThreadPool. On a two-core CI agent the pool injects roughly one thread per 500 ms, so sixteen blocked pool threads starve it.

Measured on a build pinned to two cores, 10 runs of 16 TestKits, with this change applied:

Stage	p90	max
TestKit construction	4975 ms	5262 ms
PingerActor exists after ActorOf returns	21 ms	3116 ms
Ping arrives once the actor exists	8 ms	26 ms

The construction ceiling of about 5 s is the loggers hitting akka.logger-startup-timeout on the starved pool. The old spec put a flat 5 s ExpectMsgAsync budget on the sum of the second and third rows without ever waiting for the actor explicitly; the three earlier fixes re-sized that budget without changing what it waited on. Raising the pool floor (ThreadPool.SetMinThreads(64,64)) collapses every row to under 30 ms, which rules out everything except pool starvation.

The CI log from the failed run agrees: the Akka timestamps show 2.5 to 5 s holes in pool progress, and nine CoordinatedShutdown lines land within 4 ms of each other when the pool finally frees up.

Change

One file, src/core/Akka.TestKit.Tests/TestActorRefTests/ParallelTestActorDeadlockSpec.cs.

• ActorOf returns a RepointableActorRef before the actor exists. The spec now resolves the PingerActor first, then expects its ping, so the wait is on the thing that is actually slow.
• Per-step budgets are 10 s and go through Dilated, so akka.test.timefactor applies. Construction plus one wait still fits under the 20 s [Fact] timeout, which remains the deadlock detector: a genuine circular wait during startup, the TestKit deadlock during parallel test execution with TestActor initialization #7770 class, hangs regardless of budget and trips that timeout.
• await using for teardown, so Terminate().Wait no longer blocks a pool thread during the shutdown cascade.
• Bug fix: the spec passed $"test-{id}" to the single-string TestKit overload, which parses its argument as HOCON. Every system was named test, which is why three PRs' worth of log output could not tell the TestKits apart. It now uses the (Config, name, output) overload.
• One timing line per TestKit for the next investigator.

Validation

Run	Result
30 runs, pinned to two cores	0 failures, worst actor wait 3.1 s of 10 s
Akka.TestKit.Tests whole project	332 passed, 0 failed

Follow-ups not in this PR

• The real cause is TestKit construction blocking on pool work. That belongs in TestKitBase: an async construction path, or the test loggers on a dispatcher that is not the shared pool. Until then this spec, and any user running many Akka.Hosting.TestKit tests in parallel on a small box, will see construction stall for the logger timeout under load.
• TestKitBase.CreateInitialTestActor creates its ManualResetEventSlim with using var, but InternalTestActor keeps the reference; a TestActor restart would call Set() on a disposed handle.
• The TestKit(string config, ...) overload silently accepting a system name as HOCON is an easy trap.
• Spec 317 in Akka.Streams.Tests.TCK, the other flake on the same lane, uses a hard-coded 800 ms Timeouts.DefaultTimeoutMillis that nothing scales for CI, even though the sibling timeout in the same constructors already reads an environment variable. Separate change.

[Aaronontheweb]

LGTM