Bug: Bug: Breadcrumb thread-affinity tests assume Task.Run yields a distinct thread

[drmoisan]

• Work Mode: full-bug

Summary

Two tests assert a thread-identity property while obtaining their "worker thread" from Task.Run:

• QuickFiler.Test/Viewers/ItemViewerBreadcrumbThreadAffinityTests.cs:204
  • ConfigureBreadcrumbDropDown_WorkerThread_ThrowsBoundaryDiagnostic
• QuickFiler.Test/Viewers/ItemViewerBreadcrumbThreadAffinityTests.cs:237
  • InitializeBreadcrumbPipeline_WorkerThread_ThrowsBoundaryDiagnostic

Task.Run guarantees only a thread-pool thread, never a different one. Under parallel test
execution the test body is itself running on a pool thread, so the constructing thread is also
pooled, and thread reuse can make the guard's CheckAccess() return true - at which point the
expected boundary diagnostic is never raised and the assertion fails.

.GetAwaiter().GetResult() blocking a pool thread while awaiting another compounds the pressure
under contention.

This is a determinism defect, not noise. It is the same family as the repository's standing rule
that a suite needing serial execution has already violated unit-test isolation: these tests pass or
fail depending on scheduler behaviour the test never controls.

Environment

(not provided in potential file)

Steps to Reproduce

(not provided in potential file)

Expected Behavior

(not provided in potential file)

Actual Behavior

(not provided in potential file)

Logs / Screenshots

(not provided in potential file)

Impact / Severity

(not provided in potential file)

Source

From: docs/features/potential/2026-09-14-breadcrumb-thread-affinity-tests-assume-taskrun-gives-distinct-thread.md

[drmoisan]

Correction to the Acceptance section's stated mechanism

The Acceptance section above claims the test 'can pass while the guard is never exercised at all'. That is an overstatement and should not be acted on as written.

Why it is wrong: the assertion carries a .Where(error => error.Message.Contains("InitializeBreadcrumbPipeline")) filter, so an unrelated exception does not trivially satisfy it. And the scheduler failure mode described in this issue makes the test FAIL rather than pass vacuously - which is exactly what was observed on head ce0b907.

The accurate statement is narrower and lands in the same place: the test has never been observed failing with the guard removed, so it cannot distinguish 'the guard threw' from 'some other path threw a matching InvalidOperationException'. That is still the #895 shape, and it still justifies the rule that any criterion adopted by the fix must be observed failing before acceptance - but by a different route than the body states.

Both the original claim and this correction are recorded deliberately. The conclusion survives; the stated mechanism does not, and the stated mechanism is what the next reader would otherwise act on.

This is the same discipline applied throughout run bugs-2026-09-11: see #895, where a confident diagnosis about a vacuous criterion turned out to rest on a probe rooted in a directory where the defect could not occur. The correction there was recorded in the PR body rather than only in a checkpoint, for the same reason.