Azure Service Bus multi-tenant conventional routing: message published without a tenant id is sent and never received

[jeremydmiller]

The in-file note on this class says "Needs its own issue"; that was never actioned, so the defect has been sitting behind a Flaky tag with nothing tracking it.

Bug_1933_multi_tenant_conventional_routing is tagged [Trait("Category", "Flaky")], removing 2 tests from CI. It is not flaky. Re-measured 2026-08-02 after the entity-name sanitizing fix:

• Now 1 of 2 fails, down from 2 of 2 — the broker starts fine now, so the remaining failure is not provisioning.
• 5.5m for the class.

The survivor is should_receive_message_when_published_without_tenant_id, which fails as a TrackedSession timeout after 4m28s: the message is Sent and never Received.

That is real multi-tenant conventional-routing behaviour — a message published without a tenant id never reaches its listener — not a test or provisioning problem.

Fixing it should let the tag come off and return both tests to CIAzureServiceBus.

[jeremydmiller]

Reproduced and narrowed, but not fixed — posting the evidence so this is actionable rather than leaving it as a one-line note.

Unlike #3827 (which turned out to be a test reading the wrong property), this one looks like a genuine product defect. Everything the test depends on is demonstrably correct, and the message still never arrives.

Reproduced

Baseline on main, against the emulator: 1 of 2 fails, should_receive_message_when_published_without_tenant_id, as a TrackedSession timeout. baseline_without_tenants in the same class passes. So the tenant registration is what changes the outcome.

What is NOT the cause

• Not the shared namespace. The test registers tenant "test" with Servers.AzureServiceBusConnectionString — the default namespace — while Servers.AzureServiceBusTenantConnectionString (port 5674, asb-emulator-2) exists for exactly this. That looked like the answer. It is not: repointing the tenant at its own namespace still fails (and faster — 3m25 vs 5m34, so it is not a provisioning delay either).
• Not routing. Exactly one route is resolved, to the right queue:

  PROBE route: -> asb://queue/wolverine.azureservicebus.tests.bugs.bug1933message
  

• Not a missing listener. That endpoint is registered and actively consuming:

  PROBE listener: asb://queue/wolverine.azureservicebus.tests.bugs.bug1933message status=Accepting
  

• Not provisioning / entity limits. No quota, MessagingEntityNotFound, or ServiceBusException anywhere in the log. The broker starts fine (the 2026-08-02 note had already established this).

What the session actually records

One record, then silence until the 30s timeout:

| Message Id                           | Message Type                                        | Time (ms) | Event |
| 08def26c-83df-303a-baa4-8b734d760000 | Wolverine.AzureServiceBus.Tests.Bugs.Bug1933Message |        12 | Sent  |

So: correct route → correct queue → a listener in Accepting on that very queue → message Sent → never received. With tenants registered and no tenant id on the publish, the send does not reach the listener that is demonstrably watching its destination.

Where I would look next

The sender resolution when tenants are configured but no tenant id is supplied. Sent is recorded when Wolverine hands the envelope to a sending agent, not when the broker acknowledges it — so the most likely candidates are a tenant-scoped sending agent being selected for an untenanted publish, or a send that fails silently after that point. Worth dumping the resolved ISendingAgent (and the ServiceBusClient / namespace it holds) for the untenanted publish and comparing it against the one baseline_without_tenants uses.

Incidental observation

Conventional routing on this host builds 56 Azure Service Bus queue endpoints, because it scans the whole test assembly. That is well past the 50-queue-per-namespace ceiling noted in reference_asb_emulator_entity_limits territory and is worth bounding in these tests independently of this bug — it makes every ASB conventional-routing test slow and fragile.

The [Trait("Category", "Flaky")] tag stays on for now; it should come off with the fix.