We observed a unit-test hang recently within the BlockingResultsMerger unit test (built atop AsyncResultsMerger). The root cause there (taken from PR description) was a bug in the test harness:

The fundamental bug is that DefaultBaton's _sleeping/_notified/notify_one protocol is single-consumer. With two concurrent runners a notify_one can wake the wrong thread, or a queued job (including runScheduledTasks' own sentinel) can be stolen, after which run_until never exits and both threads deadlock.

The test's main thread drove the fixture opCtx's DefaultBaton via runScheduledTasks() in results_merger_test_fixture.h while the launchAsync [Blocking Results Merger] thread was simultaneously parked in that same baton inside BlockingResultsMerger::next() -> waitForEvent.

SERVER-135564 fixed it by removing concurrent runScheduledTasks() calls on the same OperationContext and documenting the hazard in the test fixture.

This follow-up should add a broader diagnostic for code that concurrently drives the same DefaultBaton. DefaultBaton requires a single active runner. Violating that invariant can cause callers to block indefinitely, making the failure appear only as a suite timeout.

Scope

Determine the appropriate layer for detecting concurrent baton runners, preferably without changing valid production baton scheduling behavior. The diagnostic should make this misuse fail deterministically and identify the offending call site or baton where practical.

The implementation should preserve tests that intentionally drive a baton serially from a designated runner. Any test-only or debug-only restriction should be clearly separated from production behavior.

I've attached a draft implementation plan, if it's helpful (and you agree with it).