[rbuergi]

Fixes #4555

The window, measured before anything changed

Three of the four entry points deferred their whole prologue to the ThreadPool (SubscribeOn) and took their admission region inside it. Between a caller's Subscribe() returning and that prologue running, the leaf was counted by nothing — not _gateUsers, not _inFlight, not CurrentlyWaiting.

Drain() waits while anything is outstanding and gives it a grace. A leaf in that window is outstanding to nobody, so the drain never enters the grace, cancels the pool token, and the leaf then arrives to find itself cancelled — too late even to be counted in LeavesCancelledAfterGrace, which is captured before the cancel.

Scratch probe on current main (50 attempts each, subscribe then drain immediately):

Invoke         work completed=0/50   cancelled-and-NAMED=0   cancelled-and-SILENT=50
InvokeStream   work completed=0/50   cancelled-and-NAMED=0   cancelled-and-SILENT=50

Every attempt lost the work, terminated the subscriber with a cancellation, and reported LeavesCancelledAfterGrace == 0. That is accepted work discarded in silence — what #3291 exists to forbid (teardown lets accepted work finish and NAMES what it had to stop).

Fix — where the region is taken, not a new counter

Invoke, InvokeStream and SubscribeThroughPool's setup leaf now enter the region synchronously on the subscriber's thread (what InvokeBlocking has always done), and the leaf claims it when its prologue starts:

if (!TryEnterGateRegion())
    return RefuseOffSubscriber(observer);        // a refusal still leaves on a POOL thread (#4530)

var regionOwner = 0;                             // 0 unclaimed · 1 the leaf · 2 an unsubscribe
// prologue:    CAS(1,0) != 0  ⇒ already released, touch nothing, throw
// unsubscribe: CAS(2,0) == 0  ⇒ the leaf never started, release here

The CAS is the whole protocol, and it is needed because only one of the two may release: a leaf that has started still touches _gate and _poolCts, so an unsubscribe releasing the region under it would reopen the hole #2146 closed; a leaf that never started must be released by the unsubscribe, or a dropped subscription would leak a region and park Disposed forever. No new gate, no new counter, no new primitive.

Unchanged: the work still runs on a pool thread (only the admission moved — the SubscribeOn is untouched), refusals still leave off the subscriber's thread, and the region still ends with the setup leaf for SubscribeThroughPool, never with the long-lived subscription.

New cost, stated plainly: Disposed now waits for a leaf that has been accepted but whose prologue has not run, where before it could complete and leave that leaf to be refused on arrival. That is the correct direction — the pool waits for work it accepted — and it is bounded by the ThreadPool reaching the prologue.

Proof

IoPoolAcceptedWorkIsAccountedTest parks a prologue on a new OnLeafPrologueStarting seam, so the leaf is inside the window by construction rather than by racing a ThreadPool hop, then asserts both halves of the contract: the drain spends its grace, and the leaf it has to cancel is counted.

• Negative control: main + the seam only (so the control isolates the admission change), test project rebuilt → red for both entry points at Expected 0 to be greater than 0. Fix restored, rebuilt → green.
• One test-precision fix on the way: the elapsed assertion first compared against the whole grace and missed by 0.6 ms, because SpinUntil measures its budget on a clock my Stopwatch did not start. It now compares against half the grace — the discrimination is microseconds vs 1.2 s, so it never needed the precision.

Verification (local)

• dotnet build -c Release -warnaserror: 0 warnings, 0 errors for MeshWeaver.Mesh.Contract, MeshWeaver.Hosting.Test, MeshWeaver.Hosting.Orleans.Test.
• Full MeshWeaver.Hosting.Test: 795 passed, 0 failed (1 pre-existing unrelated skip).
• Whole IoPool family (12 classes incl. fix(iopool): a leaf reaching the gate mid-drain extends the grace, never consumes it (#4541) #4556's IoPoolDrainGraceTest): 64/64.
• Orleans routing + quiescence consumers: 19/19. MeshWeaver.Documentation.Test: 508/508.

Coordination

Rebased onto current main, which carries #4556 (merged). This diff does not touch Drain(), TryEnterGateRegion or the _admissionsCompleted counter that PR added — it only moves when a region is entered, which is what #4556's own comment identified as the remaining half ("this removes the masking, not the whole window").

Notes

• Recorded in Doc/Architecture/ControlledIoPooling → "ADMISSION is taken on the subscriber's thread, so 'accepted' means one thing".
• What's New: skipped deliberately — internal teardown accounting, no user-visible change.
• No public surface added or removed (the seam is internal); no i18n keys. No Pairs-with:, Implementers: or Mirror-sync:.

🤖 Generated with Claude Code

[Copilot]

🔵 Needs a closer look

It changes core IoPool concurrency/admission semantics on hot entry points, so it warrants final human review despite good targeted test coverage.

Pull request overview

This PR fixes a teardown-accounting hole in IoPool where work could be “accepted” (the caller’s Subscribe() returned) but still be invisible to Drain() until the ThreadPool ran the leaf prologue, allowing drains to cancel that work without it being counted or named (issue #4555). It moves the admission region to be taken synchronously on the subscriber’s thread (while still running the actual work on the pool thread), adds a small CAS-based ownership protocol to ensure the region is released exactly once, and pins the behavior with a deterministic regression test plus documentation.

Changes:

• Take the IoPool admission region synchronously at subscribe time for Invoke, InvokeStream, and SubscribeThroughPool’s setup leaf, eliminating the “Subscribe-returned-but-unaccounted” window.
• Add a test seam (OnLeafPrologueStarting) and a regression test that deterministically holds a leaf in the window and asserts Drain() spends grace and counts the cancellation.
• Document the “admission on subscriber thread” rule and the rationale/protocol in ControlledIoPooling.md.

File summaries

File	Description
test/MeshWeaver.Hosting.Test/IoPoolAcceptedWorkIsAccountedTest.cs	Adds a deterministic regression test for #4555 using the new prologue seam.
src/MeshWeaver.Mesh.Contract/Threading/IoPool.cs	Moves admission to the subscriber thread and implements single-release ownership (leaf vs unsubscribe) for affected entry points.
src/MeshWeaver.Documentation/Data/Architecture/ControlledIoPooling.md	Documents the admission-thread rule, the failure mode, and the CAS protocol used to fix it.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results (shard 0)

264 tests   264 ✅  2m 12s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit adf3a79.

[github-actions]

Test Results (shard 1)

533 tests   533 ✅  1m 11s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit adf3a79.

[github-actions]

Test Results (shard 3)

1 397 tests   1 397 ✅  3m 5s ⏱️
    2 suites      0 💤
    2 files        0 ❌

Results for commit adf3a79.

[github-actions]

Test Results (shard 4)

    2 files      2 suites   5m 6s ⏱️
1 763 tests 1 763 ✅ 0 💤 0 ❌
1 764 runs  1 764 ✅ 0 💤 0 ❌

Results for commit adf3a79.

[github-actions]

Test Results (shard 5)

    4 files      4 suites   5m 33s ⏱️
2 271 tests 2 271 ✅ 0 💤 0 ❌
2 275 runs  2 275 ✅ 0 💤 0 ❌

Results for commit adf3a79.

[github-actions]

Test Results (shard 2)

1 764 tests   1 764 ✅  11m 46s ⏱️
    3 suites      0 💤
    3 files        0 ❌

Results for commit adf3a79.

[github-actions]

Test Results

   13 files     13 suites   28m 55s ⏱️
7 992 tests 7 992 ✅ 0 💤 0 ❌
7 997 runs  7 997 ✅ 0 💤 0 ❌

Results for commit adf3a79.