PostSharp.Patterns TimeSensitiveTest target deadlocks on startup (reproducible hang in threading tests, regression on 2026-06-10)

[gfraiteur]

Summary

The TimeSensitiveTest MSBuild target of Tests\Patterns\PostSharp.Patterns.Tests.proj (the PostSharp.Patterns threading / time-sensitive test suite, .NET Framework) deadlocks on startup. The target launches, produces no test output whatsoever, and hangs indefinitely until the build is killed manually.

This is reproducible, not a one-off flake: it has occurred on consecutive CI runs of the Test .NET Framework (X64, VS 17.0, .NET SDK 9.0) configuration on release/2026.0, each time freezing at the exact same point.

Observed behavior

On each affected run, tests execute normally for ~30 min, then the log shows:

[Step 2/3] msbuild Tests\Patterns\PostSharp.Patterns.Tests.proj /t:TimeSensitiveTest
           -p:Configuration=Release -p:TestPlatform=NetFramework
[Step 2/3] PostSharp.Patterns (running for 40m:33s)     <-- then ZERO output
... build manually canceled ~40 min later ...

No per-test line is ever emitted for the TimeSensitiveTest target — it hangs immediately on launch.

Evidence (CI build IDs)

Build	Date (UTC)	Result	Tests passed before hang
#18 (325453)	2026-06-10 06:07	hung ~73 min, manually canceled	4669
#21 (325690)	2026-06-10 08:17	hung ~74 min, manually canceled	4669

The identical "passed: 4669, ignored: 238" count on both runs confirms the hang occurs at precisely the same point (right as the TimeSensitiveTest target starts).

Regression window

This is new as of 2026-06-10. The immediately preceding run, #17 (325377) on 2026-06-09 23:51, completed the full suite (5109 tests passed). A change landed on release/2026.0 between 2026-06-09 23:51 and 2026-06-10 06:07 that introduced or exposed this deadlock.

Impact

CI on release/2026.0 cannot complete the test stage; runs must be killed manually.

Suggested next step

Reproduce locally with:

msbuild Tests\Patterns\PostSharp.Patterns.Tests.proj /t:TimeSensitiveTest -p:Configuration=Release -p:TestPlatform=NetFramework

and capture a hang dump (dotnet-dump / procdump) to identify the deadlocked test and thread. The MSBuild binlog was not published on the CI runs because the build was interrupted, so a local repro is the fastest path to the exact culprit.

[gfraiteur]

Related product bug: #24 — the underlying defect is an unbounded dispose/finalizer wait in the Redis caching backend (PostSharp.Patterns.Caching.Backends.Redis). The TimeSensitiveTest target runs the Caching/Redis tests, and a transient Redis pub/sub hiccup leaves the notification-processing thread's completion signal unset, so a dispose/finalizer blocks forever and keeps the test host from exiting — which is the hang seen here.

Note: the stated regression window does not hold — release/2026.0 HEAD (3f4ea892fe, last commit 2026-06-09 15:47 UTC) was unchanged between the passing run and the hung runs, so both built identical source. This is an intermittent, environment-triggered deadlock on unchanged code, tracked as #24.