Share one pinned Pulsar broker per job instead of one container per process (GH-3799)

[jeremydmiller]

Closes #3799.

PulsarContainerFixture starts a Pulsar container from a [ModuleInitializer], which runs once per process. The supervisor partitions this project across worker processes (2, 3, 6 and 24 observed depending on machine load) and the retry harness spawns another fresh process per retried test — so one CIPulsar run could ask Docker for that many concurrent Pulsar standalone brokers. That is not a small image.

docker-compose.yml already defines a pinned pulsar service that nothing used, and the fixture already has the escape hatch — WOLVERINE_PULSAR wins over starting a container, "same shape as Servers.cs". That variable was set nowhere. So the fix is mostly wiring: start the compose broker once per job and point every worker process at it.

The readiness gate is the half that matters most

With Docker starved, the old arrangement did not fail. It sat at

[INF]   Filter kept 224 of 224 discovered test(s)
[INF]   224 test(s): 224 batched, 0 isolated

forever — no Pulsar container running, no timeout, nothing in the output naming Docker. A silent hang is the worst failure shape we have, because it looks identical to slow. A gate that throws turns it into a named failure in the job that owns it.

The probe asks /admin/v2/brokers/health rather than opening a socket. Pulsar standalone accepts on 6650 well before it will serve, and #3814 measured exactly what a TCP-only gate is worth on Kafka: it passed at 0.0s every time while the broker was still ~3 seconds from ready. Budget is 3 minutes, since a cold Pulsar standalone genuinely takes tens of seconds.

On the third item in the issue

The image pin is already done — both PulsarContainerFixture.PulsarImage and docker-compose.yml are on apachepulsar/pulsar:4.2.4, and the fixture carries the note about :latest having moved that same day. Nothing to do there.

Verification

Ran the CIPulsar target locally:

pulsar containers BEFORE: 1
Starting docker services: pulsar postgresql
Pulsar is up and ready (attempt 1)
=== Wolverine.Pulsar.Tests: 224 passed (0 retries, 2 worker processes) ===

224 passed, and exactly one Pulsar container for the whole run — two worker processes that would previously have started two of their own. docker ps -a --filter ancestor=apachepulsar/pulsar:4.2.4 shows only wolverine-pulsar-1 from compose, so no Testcontainers broker was created at any point.

The probe itself was checked against a real container before wiring it in: GET /admin/v2/brokers/health → 200 ok.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WHAuhdWS3XeAk16swV9G8m