[christopherread]

Fixes the intermittent NetMQ failures in CI's "Test transports against brokers" step. Example: run 40212679268, attempt 1, where TestSendingAndReceivingStringsOverLocalHost and TestSlowJoiner.FirstMessageReachesASubscriberThatConnectsLate both lost their first message.

Cause

MessageSource started each subscription's receive loop with Task.Run. That loop blocks for as long as the subscription lasts, so:

• every subscription permanently held a thread-pool thread;
• Subscribe blocked until its loop got a thread.

The NetMQ tests start about a dozen subscriptions at once. On CI's small runners the pool adds threads gradually, so subscribers were delayed. The CI log shows it:

• every NetMQ test class started at 16:40:21, and the service bus test didn't send its first command until 16:40:26, after its Subscribe calls returned;
• in the same window, the two failing tests' publishers waited their full 5 seconds for a subscriber, gave up, and published anyway, so the first message was dropped (ZeroMQ's "slow joiner").

The same thing can happen in production, in any app whose thread pool is busy when it subscribes.

Fix

The receive loop now runs as a LongRunning task, on a thread of its own. Subscribing no longer depends on the thread pool, and subscriptions no longer hold pool threads.

Testing

• Reproducing test first: TestMessageSourceThreading.SubscribingDoesNotWaitForAThreadPoolThread saturates the thread pool with blocked work and checks that subscribing still starts within 2 seconds.
  • Before the fix it failed: "Subscribing waited for a thread-pool thread to start receiving".
  • It runs in a collection with parallelization disabled, so filling the pool doesn't affect other tests.
• After the fix: all 6 NetMQ tests, including the broker-style ones, passed in 8 consecutive local runs.
• What I couldn't reproduce: the CI failure itself. The tests passed locally even when simulating 1 or 2 cores, and under CPU load. The evidence that starvation causes the CI failure is the CI log's timing; this PR's CI runs are the real check.

Only Obvs.NetMQ/MessageSource.cs changes in the library. The long-running v7 branch has the same code and will get this when master is next merged into it.

🤖 Generated with Claude Code