GH-3950: assert that listeners resume after the connection dies underneath them

[jeremydmiller]

Addresses suggestion 2 of #3950 — "Confirm Wolverine recovers."

Why

A rejected delivery tag on a busy channel can cost the whole connection: SessionManager.Lookup does an indexer read on a dictionary it may have just mutated, throws KeyNotFoundException on the receive loop, and RabbitMQ.Client escalates that into a library-initiated close (code=541). Wolverine cannot catch it — it is raised on the client's own MainLoop thread.

So the only part Wolverine owns is what happens next, and as the issue puts it, that part was observed to work and asserted nowhere. This turns it into a guarantee.

What it does

Kills the connection from the broker side via the management API rather than provoking the 541 race. The race is timing-dependent and would make a flaky test, and a forced close is indistinguishable from Wolverine's point of view — an unsolicited shutdown it did not initiate. What's pinned is the recovery contract, not the client bug.

Asserting on ReconnectAttempts alone would be too weak: a recovered connection is not a recovered consumer. ConnectionMonitor has to rebuild every tracked channel agent on recovery, and #3370 is exactly the case where an agent falling out of that list was one drop away from being permanently ghosted. So the real assertion is that a message published after the kill is still received — with a baseline send first, so a failure can't be read as "it never worked".

Two things I measured rather than assumed

Both of which my first attempt got wrong, and both now encoded in the test:

• /api/connections lags the actual TCP connect on RabbitMQ 4.x. Measured locally as empty at 4s and populated at 8s, with the host already up and passing traffic. Reading it once reported "no connection to kill" against a perfectly healthy host, so the lookup polls.
• The kill is scoped by a per-test ClientProvidedName, so a run cannot take down a concurrently executing test's connections. Bobcat runs this project across several worker processes against one broker, which makes that a correctness requirement rather than tidiness.

Verification

New test, repeated isolated runs	4/4, ~10s each
Full Wolverine.RabbitMQ.Tests	503/503, with the kill running alongside everything else

The suite result matters more than usual here: a test that force-closes broker connections is exactly the kind that can perturb its neighbours, so I ran the whole project rather than the class.

Not included

• Suggestion 1 (report the SessionManager.Lookup defect upstream to rabbitmq-dotnet-client) — that's an outward-facing action, so I've left it for you to file.
• Suggestion 3 (whether a rejected settle should proactively quiesce the channel) — a behavior change rather than coverage, worth its own PR and its own discussion.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JG8Un6iNeyXECKJk3jo5uC