Residual from the conjoined EF Core multi-tenancy epic (#3465), Phase 3 (#3464). The #3464 design promised:
Descriptors: extend TenantedDbContextUsageSource<T> / DbContextUsage so a conjoined context advertises DatabaseCardinality.DynamicMultiple plus tenant ids on its single DatabaseDescriptor, giving CritterWatch what it needs to show the Tenants tab with actions.
That bullet did not land in #3498. As shipped (6.21.0 / 6.22.0-alpha.1):
- The tenancy-style discriminator in
src/Persistence/Wolverine.EntityFrameworkCore/Internals/DbContextUsageSource.cs switches on the IDbContextBuilder<T> implementation type name and only knows TenantedDbContextBuilderByDbDataSource / TenantedDbContextBuilderByConnectionString; ConjoinedDbContextBuilder<T> falls through to "Single".
ConjoinedDbContextBuilder<T>.Cardinality returns DatabaseCardinality.Single and FindAllAsync() returns only the main context, so the descriptor carries no tenant ids.
- No test in
EfCoreTests.MultiTenancy/ConjoinedTenancy/ asserts the DbContextUsage shape for a conjoined registration.
So a conjoined app looks exactly like a plain single-DB app to CritterWatch's descriptor-driven UI. Tenant management still lights up (the IDynamicTenantSource<string> registration shipped and is what the satellite handlers fan out over), but the UI gating/badging side (JasperFx/CritterWatch#720) has nothing to distinguish conjoined from single.
Acceptance criteria
- A conjoined registration's
DbContextUsage is distinguishable from a plain single-DB one (a "Conjoined" tenancy style and/or the promised DynamicMultiple cardinality — settle the exact shape with the CritterWatch#720 consumer, since conjoined is one physical database with a dynamic tenant list, which neither existing cardinality models cleanly).
- Tenant ids from the
wolverine_tenants registry are surfaced on the descriptor (masked connection info as today).
- Compliance-battery coverage in
EfCoreTests.MultiTenancy/ConjoinedTenancy/ asserting the descriptor shape.
🤖 Generated with Claude Code
Residual from the conjoined EF Core multi-tenancy epic (#3465), Phase 3 (#3464). The #3464 design promised:
That bullet did not land in #3498. As shipped (6.21.0 / 6.22.0-alpha.1):
src/Persistence/Wolverine.EntityFrameworkCore/Internals/DbContextUsageSource.csswitches on theIDbContextBuilder<T>implementation type name and only knowsTenantedDbContextBuilderByDbDataSource/TenantedDbContextBuilderByConnectionString;ConjoinedDbContextBuilder<T>falls through to"Single".ConjoinedDbContextBuilder<T>.CardinalityreturnsDatabaseCardinality.SingleandFindAllAsync()returns only the main context, so the descriptor carries no tenant ids.EfCoreTests.MultiTenancy/ConjoinedTenancy/asserts theDbContextUsageshape for a conjoined registration.So a conjoined app looks exactly like a plain single-DB app to CritterWatch's descriptor-driven UI. Tenant management still lights up (the
IDynamicTenantSource<string>registration shipped and is what the satellite handlers fan out over), but the UI gating/badging side (JasperFx/CritterWatch#720) has nothing to distinguish conjoined from single.Acceptance criteria
DbContextUsageis distinguishable from a plain single-DB one (a"Conjoined"tenancy style and/or the promisedDynamicMultiplecardinality — settle the exact shape with the CritterWatch#720 consumer, since conjoined is one physical database with a dynamic tenant list, which neither existing cardinality models cleanly).wolverine_tenantsregistry are surfaced on the descriptor (masked connection info as today).EfCoreTests.MultiTenancy/ConjoinedTenancy/asserting the descriptor shape.🤖 Generated with Claude Code