Fix #4598: provision per-tenant event partition + sequence under sharded tenancy

[jeremydmiller]

Fixes #4598.

The docs at martendb.io/events/multitenancy.html#per-tenant-event-partitioning claim per-tenant event partitioning composes with the Sharded Multi-Tenancy with Database Pooling model. In 9.4.0 it didn't: runtime-provisioned sharded tenants got the document LIST partitions but not the per-tenant mt_events_sequence_{suffix} sequence. The first event append for such a tenant failed with:

42P01: relation "{schema}.mt_events_sequence_<tenant>" does not exist

because quick-append calls nextval(mt_events_sequence_<suffix>) and the sequence creation lived only inside AdvancedOperations.AddMartenManagedTenantsAsync — DefaultTenancy-guarded and unreachable on a sharded store.

Three coordinated changes

1. Bump JasperFx 2.5.0 → 2.8.0

Picks up jasperfx#413's IDynamicTenantSource<T>.AddTenantAsync(tenantId, ct) → string auto-assign provisioning overload that ShardedTenancy now implements (part 3).

2. Wire the sequence provisioning into the sharded path

• Extract AdvancedOperations.AddMartenManagedTenantsAsync's inline sequence-creation loop into PerTenantEventSequences.EnsureSequencesAsync so both call sites share one idempotent CREATE SEQUENCE IF NOT EXISTS … implementation.
• ShardedTenancy.createPartitionsForTenant calls the helper against the assigned shard database (not the default) right after AddPartitionToAllTables. Tenant id == partition suffix per the existing 1:1 assumption.
• AdvancedOperations.AddMartenManagedTenantsAsync's DefaultTenancy guard now routes sharded calls through ShardedTenancy.AddTenantAsync per tenant (rejecting suffix-overrides since the sharded model assumes tenant id == suffix). Master-table tenancy keeps throwing, with a clearer message pointing at the caller-supplied connection-string path.

3. Implement IDynamicTenantSource<string> on ShardedTenancy

So the JasperFx 2.8.0 store-agnostic admin extensions work end-to-end without sniffing the concrete tenancy type:

• AddTenantAsync(tenantId, databaseId) wraps AssignTenantAsync.
• AddTenantAsync(tenantId, ct) → string (the auto-assign override) runs the same findOrAssignTenantDatabaseAsync + createPartitionsForTenant path that Advanced.AddTenantToShardAsync drives and returns the resolved database id.
• AddTenantToShardAsync delegates to it — one code path.
• Disable/enable lifecycle is not implemented on sharded tenancy yet (no disabled column in the assignment table); those methods throw NotSupportedException with a clear message until a consumer needs them.

4. Conditional DI registration in AddMarten(services, StoreOptions)

Per the issue addendum. So IServiceProvider.GetServices<IDynamicTenantSource<string>>() surfaces the configured tenancy when (and only when) it's dynamic. Mirrors the existing IMasterTableMultiTenancy registration pattern; DefaultTenancy / StaticMultiTenant keep returning an empty enumerable — the graceful-no-op shape the JasperFx admin extensions rely on. Without this, store-agnostic consumers (CritterWatch) would either stay Marten-coupled or no-op.

Tests

src/MultiTenancyTests/sharded_tenancy_per_tenant_events_tests.cs (new, 8 tests):

Test	What it pins
append_event_for_runtime_provisioned_tenant_does_not_throw_42P01	Headline regression — would throw on 9.4.0.
per_tenant_event_sequence_lives_in_the_assigned_shard	Sequence lands in the assigned shard only (not in default DB, not in sibling shards).
per_tenant_event_partition_also_created_in_assigned_shard	mt_events_<tenant> partition materialises on the assigned shard.
explicit_AddTenantToShardAsync_provisions_the_event_sequence_too	Sibling code path (explicit target) hits the same provisioning.
IDynamicTenantSource_AddTenantAsync_returns_assigned_database_id_and_provisions	#413 auto-assign override — returns the resolved id; append works.
IDynamicTenantSource_caller_supplied_overload_assigns_to_named_shard	#413 caller-supplied overload routes to the named shard.
IDynamicTenantSource_is_registered_in_the_container_when_tenancy_is_sharded	DI: present on a sharded store.
IDynamicTenantSource_is_NOT_registered_when_tenancy_is_default	DI: absent on default tenancy (graceful no-op).

Regression sweep (net9.0)

• sharded_tenancy_tests: 12/12 PASS
• use_tenant_partitioned_events_*: 32/33 PASS — the single fail (use_tenant_partitioned_events_admin_overrides.delete_projection_progress_with_tenant_id_drops_only_that_tenants_rows) is a pre-existing partition-setup race independent of this work.

Note on a related-but-separate bug

While writing the tests I hit a second issue: the runtime partition-attach on mt_events (Weasel's additivelyMigrateTablesForNewPartitions) fails with 42P16: cannot drop inherited constraint mt_events_tenant_id_stream_id_fkey when the parent schema was applied via ApplyAllConfiguredChangesToDatabaseAsync before runtime tenant provisioning. The tests therefore exercise the lazy-apply flow (parent schema is created on first append after AddTenantToShardAsync) which matches typical production usage anyway. The eager-apply path will need its own fix (Marten or Weasel side); I treated it as out-of-scope for #4598 since it's distinct from the reported 42P01 sequence-missing failure.

Related: jasperfx#413 (dynamic tenancy auto-assign abstraction, shipped in 2.8.0), CritterWatch#267, CritterWatch#269.

🤖 Generated with Claude Code