MySQL: resolve queue tables per tenant database (GH-3859)

[jeremydmiller]

Fixes #3859.

Contains #3858. The count assertion here depends on the forEveryDatabase fix from #3858, so that commit is carried on this branch rather than stacking — a PR based on a feature branch gets no CI in this repo. Merge #3858 first and this rebases to a single commit.

The bug

A MySQL schema is a database. The transport qualifies its queue tables with one transport-wide name:

internal class QueueTable : Table
{
    public QueueTable(MySqlTransport parent, string tableName) : base(
        new DbObjectName(parent.TransportSchemaName, tableName))   // "wolverine_queues"

So on a multi-tenanted host every tenant data source resolves wolverine_queues.wolverine_queue_<name> to the same physical table. Four registered databases, one queue table between them:

MySQL, before                          MySQL, after
--------------------------------       --------------------------------
wolverine_queues  wolverine_queue_x     wolverine   wolverine_queue_x
                                        tenant_db1  wolverine_queue_x
(tenant_db1/2/3 have none)              tenant_db2  wolverine_queue_x
                                        tenant_db3  wolverine_queue_x

Consequences:

• No tenant isolation. Every tenant's sends landed in one table.
• CountAsync() multiplied rather than summed — with 10 rows physically present it reported 40. That feeds GetAttributesAsync(), so it is user visible queue depth.
• Purge / Setup / Teardown / Check repeated their work against that one table.

PostgreSQL is unaffected: its TransportSchemaName is a schema nested inside each tenant database, so each tenant already had its own copy. Verified both ways.

The fix

MySqlQueue.SchemaFor(MySqlDataSource) resolves the schema from the connecting data source's own database when the host is multi-tenanted, and the sender, listener, and every forEveryDatabase operation build their identifiers through it. Single database hosts are untouched and keep using TransportSchemaName.

Verification

Evidence	Without fix	With fix
every_tenant_database_owns_its_own_queue_tables	fails	passes
a_tenants_message_lands_only_in_that_tenants_database	fails	passes
counts_sum_across_databases_instead_of_multiplying	fails	passes
Full MySqlTests suite	—	116 / 116
PostgresqlTests.MultiTenancy	—	21 / 21
dotnet build wolverine.slnx -c Release -f net9.0	—	clean, 0 warnings

The full MySQL suite passing matters most here: it covers the single-database transport paths that must not change.

Known wart

Bootstrap still leaves an empty, unused pair of tables in the wolverine_queues database on a multi-tenanted host. A provisioning pass runs before the transport has resolved its tenancy, so it provisions against TransportSchemaName. I confirmed by elimination that this is not the Store.AddTable registration — disabling it entirely does not stop it. Nothing reads or writes those tables: every sender, listener and count goes through the per-tenant resolution. I left it rather than restructure transport bootstrap ordering inside a bug fix; happy to chase it separately if you'd rather not ship the clutter.

Not addressed here

#3860 — the same root cause in the tenant message stores (wolverine_incoming_envelopes and friends also share one schema across tenants). That one is a design decision about how MySQL should map Wolverine's two-level schema.table model, not a bug fix, so it is deliberately out of scope.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JKfy5EzLX1i149gjUb3Tfg