Conventional routing on Azure Service Bus fails broker initialization (hidden behind [Flaky] since March)

[jeremydmiller]

Conventional routing against Azure Service Bus fails to initialize the broker. Every affected test fails 100% of the time, deterministically, on a clean emulator — this is not flakiness, and it has been hidden behind [Trait("Category", "Flaky")] since 2026-03-21.

The failure

Wolverine.Transports.BrokerInitializationException : Unable to initialize the Broker asb in time

21 of 24 failures in the suite carry that exact message. Each one burns ~2m11s–2m27s on the timeout before failing, which is why the affected classes dominate the suite's wall clock.

Measured evidence

Full Wolverine.AzureServiceBus.Tests run, 2026-08-02, net9.0, Release, serial, against a freshly recreated emulator (servicebus-emulator:2.0.1) with the GH-3783 readiness gate in place, retries off:

304 tests, 24 failed, 67.6 minutes — of which 57.0 minutes is these classes.

class	tests	failed	time
ConventionalRouting.conventional_listener_discovery	6	5	12.55m
ConventionalRouting.when_discovering_a_listening_endpoint_with_all_defaults	4	4	10.55m
Bugs.Bug_1933_multi_tenant_conventional_routing	2	2	7.70m
ConventionalRouting.when_discovering_a_sender_with_all_defaults	3	3	7.13m
ConventionalRouting.when_discovering_a_listening_endpoint_with_overridden_queue_naming	3	3	6.09m
ConventionalRouting.Broadcasting.end_to_end_with_conventional_routing	1	1	2.99m
ConventionalRouting.end_to_end_with_conventional_routing_with_prefix	1	1	2.78m
ConventionalRouting.end_to_end_with_conventional_routing	1	1	2.67m
ConventionalRouting.discover_with_naming_prefix	1	1	2.39m
end_to_end	6	2	2.03m
Bugs.Bug_2307_batching_with_conventional_routing	1	1	0.08m

Every single one is a conventional-routing test.

A clue worth starting from

ConventionalRouting.when_using_handler_type_naming (2 tests) was never tagged, has therefore been running in CI all along, and passes. Whatever it does differently from its eleven neighbours is probably the shortest path to the cause.

Bug_2307_batching_with_conventional_routing is also worth noting separately: it fails in 0.08m, not on the 2-minute broker timeout, so it may be a different (or downstream) failure.

Why nobody noticed

These were tagged in a bulk sweep on 2026-03-21 (commits with messages like "Tag all ConventionalRouting tests as Flaky"), so they have not run in CI for over four months. None of the tags recorded a reason, a number, or an issue link, so there was nothing to indicate the tag was hiding a hard failure rather than a timing race.

Separately, GH-3783 found the ASB readiness gate had been declaring the emulator ready ~26s before its management API could serve provisioning. That is plausibly what the March sweep was actually measuring — but it does not explain these: the numbers above were taken after that fix, on a cold, clean emulator.

Reproducing

docker compose up -d asb-emulator
dotnet test src/Transports/Azure/Wolverine.AzureServiceBus.Tests/Wolverine.AzureServiceBus.Tests.csproj \
  --framework net9.0 --filter "FullyQualifiedName~ConventionalRouting"

Recreate the emulator (docker compose rm -sf asb-emulator asb-sql) between runs — accumulated entities from prior runs change the timings.

Scope

Fixing this restores 29 tests and, more importantly, tells us whether conventional routing on Azure Service Bus works at all — the tests are the only coverage of that combination and they have been dark since March.

[jeremydmiller]

Root-caused and fixed in #3789. The premise in the original write-up was right that this is a hard,
deterministic failure — but the cause is one line, and it is not a timeout.

What it actually was

Conventional routing derives entity names from the message type. Handle(BatchedItem[] items) —
an array — produced the queue name wolverine.azureservicebus.tests.bugs.batcheditem[], and
Azure Service Bus rejects [ and ]:

400 SubCode=40000. '...batcheditem%5B%5D' contains character(s) that is not allowed by Service Bus.

One handler took down broker startup for every conventionally-routed host in the whole assembly.
That is exactly why the clue in this issue pointed the right way: when_using_handler_type_naming
calls DisableConventionalDiscovery().IncludeType(...), so it never sees BatchedItem[].

The dates close it: Handle(BatchedItem[]) landed in 5aeefe306 on 2026-03-16, and the
"Tag all ConventionalRouting tests as Flaky" sweep was 2026-03-20/21. The sweep was tagging a
regression that had arrived four days earlier.

Why it read as a timeout for four months

BrokerTransport.InitializeAsync retries 20 times over two minutes and reports only "Unable to
initialize the Broker asb in time". The real error went to a log line, inside a job already dismissed
as flaky. A 400 was never going to succeed on attempt 20.

BrokerInitializationException now carries the last attempt's exception. That change is what made
everything below findable in minutes instead of hours, and it is probably the most reusable part
of the fix.

Two more failures were stacked behind the first

Both only became visible once the 400 was gone and the cause was attached:

1. A second unsanitized name. SubscriptionNameForListener results skip the sanitizing that
   MessageRoutingConvention applies to identifiers, so a correctly-named topic batcheditem__ got
   a subscription named batcheditem[].
2. The emulator's 50-queue namespace cap. Unrestricted conventional routing asks for 28 queues
   per host, so two test classes in one process hit SubCode=40300 ... Actual: 50, Max allowed: 50
   — reported, once again, as a broker-init timeout. Two classes also never purged the emulator in
   teardown; discover_with_naming_prefix left 28 prefixed queues behind every time.

Correcting two things in the original evidence table

• The 57 of 68 minutes attributed to these classes was almost entirely the 20×5s retry loop, not
  the tests. The whole ConventionalRouting namespace now runs in 6m3s, down from 32m38s.
• Three of the eleven re-tagged classes are not this issue at all. Their tags said "broker
  timeout"; none of them is one now, and I have corrected each tag in place rather than leaving them
  pointing here:

class	now	actual cause
end_to_end	2 of 6	session handling — unrelated
Bug_2307	1 of 1, in 5 seconds	plain assertion — EndpointName is the raw type name, a naming bug in the GH-2307 fix itself
Bug_1933	2 of 2 → 1 of 2	TrackedSession timeout; message Sent, never Received

Each deserves its own issue. Deliberately not folded in here.

Result

CIAzureServiceBus: 271 → 300 passing, 0 retries, verified on a freshly recreated emulator, with
every class also checked by name in isolation.