Summary
Wolverine.Marten's IntegrateWithWolverine() puts the message-durability tables (envelopes, dead letters, nodes/assignments, …) in the Marten store's DatabaseSchemaName by default — so two Marten-backed services with distinct document schemas are automatically isolated.
Wolverine.Polecat's IntegrateWithWolverine() does not mirror this: with no explicit MessageStorageSchemaName it defaults durability to SQL Server master / the wolverine schema, ignoring the Polecat DatabaseSchemaName. So multiple Polecat services with distinct document schemas still share the same durability tables (including wolverine_dead_letters) unless each one explicitly sets MessageStorageSchemaName.
Why it's a footgun
Sharing a durability schema silently couples services: shared node/assignment/agent-restriction state (the leader-election / agent-distribution bleed) and shared dead letters. We hit the dead-letter version of this in CritterWatch: two Polecat sample services (distinct document schemas polecat_trips / polecat_repair_shop) both reported database=wolverinedb://sqlserver/localhost/master/wolverine with an identical dead-letter count, because each one's SummarizeAllAsync read the same shared table.
Repro (shape)
// Two services, distinct Polecat document schemas, both IntegrateWithWolverine() with no
// MessageStorageSchemaName → both land in master/wolverine and share durability.
services.AddPolecat(m => { m.ConnectionString = cs; m.DatabaseSchemaName = "polecat_trips"; })
.IntegrateWithWolverine();
// vs Wolverine.Marten, where the same shape isolates into the "polecat_trips" schema.
Ask
Align Wolverine.Polecat with Wolverine.Marten: default MessageStorageSchemaName (and TransportSchemaName) to the Polecat DatabaseSchemaName when not explicitly set, so distinct-schema Polecat services are isolated by default. (Workaround today: set o.MessageStorageSchemaName / o.TransportSchemaName explicitly per service.)
Found via CritterWatch #504.
Summary
Wolverine.Marten'sIntegrateWithWolverine()puts the message-durability tables (envelopes, dead letters, nodes/assignments, …) in the Marten store'sDatabaseSchemaNameby default — so two Marten-backed services with distinct document schemas are automatically isolated.Wolverine.Polecat'sIntegrateWithWolverine()does not mirror this: with no explicitMessageStorageSchemaNameit defaults durability to SQL Servermaster/ thewolverineschema, ignoring the PolecatDatabaseSchemaName. So multiple Polecat services with distinct document schemas still share the same durability tables (includingwolverine_dead_letters) unless each one explicitly setsMessageStorageSchemaName.Why it's a footgun
Sharing a durability schema silently couples services: shared node/assignment/agent-restriction state (the leader-election / agent-distribution bleed) and shared dead letters. We hit the dead-letter version of this in CritterWatch: two Polecat sample services (distinct document schemas
polecat_trips/polecat_repair_shop) both reporteddatabase=wolverinedb://sqlserver/localhost/master/wolverinewith an identical dead-letter count, because each one'sSummarizeAllAsyncread the same shared table.Repro (shape)
Ask
Align
Wolverine.PolecatwithWolverine.Marten: defaultMessageStorageSchemaName(andTransportSchemaName) to the PolecatDatabaseSchemaNamewhen not explicitly set, so distinct-schema Polecat services are isolated by default. (Workaround today: seto.MessageStorageSchemaName/o.TransportSchemaNameexplicitly per service.)Found via CritterWatch #504.