Record the MQTT Broken pipe flake as accepted retry debt (GH-3763)

[jeremydmiller]

Comments only; no behaviour change.

listen_with_topic_wildcards.broadcast and broadcast_to_topic_by_user_logic.route_by_derived_topics_2 each cost one retry in CIMQTT5, failing with the same error in the same run:

MQTTnet.Exceptions.MqttCommunicationException : Broken pipe
  ---- System.Net.Sockets.SocketException : Broken pipe

Neither is tagged Category=Flaky, deliberately. A tag would stop them running, and the trade this repo has been making all along is that a test which runs and occasionally retries is worth more than a test that runs nowhere. This is visible debt in the retry ledger rather than hidden debt in an exclusion list — the same trade already recorded on multi_tenancy_through_virtual_hosts.

What the note buys

The search that has already been done. Three candidates tested and eliminated — recorded so nobody repeats them:

candidate	verdict
Teardown ordering — both classes stop the broker before the hosts still connected to it, and 7 of 12 broker-using classes share the shape	Refuted. A faithful reproduction (sender + receiver, real tracked broadcast, broker-first teardown) throws nothing in 10 runs, either ordering
Port collision between worker processes via PortFinder's TOCTOU	Refuted. MQTTnet throws SocketException: Address already in use, which fails the class at InitializeAsync rather than breaking a pipe mid-test
Local reproduction under concurrency	No occurrence in six concurrent full-suite runs

Left standing is a keep-alive drop under CI load, which needs a call site. #3811 makes the ledger record one, so the next occurrence writes its stack into the test-ledger-CIMQTT5 artifact.

The note also says plainly what it costs — one retry, never a red main, two rounds of investigation already spent — so the next reader can weigh that before starting a third.

Also here

The note on multi_tenancy_through_virtual_hosts asked for a next step — "dump the tracked session on the FIRST attempt rather than infer from the assertion" — that has since been built (#3810) and now happens on its own. Amended with its first captured failure:

System.Exception : No messages of type MultiTenantResponse were received
Activity detected: | Service (Node Id) | Message Id | Message Type | ...

The request never produced its response, which is consistent with the fixed queue names already under suspicion there — without yet proving them.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WHAuhdWS3XeAk16swV9G8m