Investigate: DetermineSagaIdType asks the default Marten store, ignoring the chain's ancillary store

[jeremydmiller]

Spun out of GH-4439 as an investigation rather than a bug report, because I have not yet built a case that reproduces user-visible damage.

The observation

MartenPersistenceFrameProvider.DetermineSagaIdType resolves the identity type through the default store:

public Type DetermineSagaIdType(Type sagaType, IServiceContainer container)
{
    var store = container.GetInstance<IDocumentStore>();
    var documentType = store.Options.FindOrResolveDocumentType(sagaType);

    return documentType.IdType;
}

This is the same store-blindness GH-4439 fixed one call later in the same method. WriteModelAttribute.Modify calls DetermineSagaIdType to get the id type it then searches the message for, so for a handler routed to an ancillary store with [MartenStore(typeof(IMyStore))] / [Storage(typeof(IMyStore))], the id type comes from a store that is not the one the handler writes to.

For the common case this is harmless: the aggregate is not registered on the default store, Marten resolves a document mapping for it on the fly, and a plain Guid Id yields Guid either way. The question is what happens when the two stores would not agree, e.g.

• the ancillary store configures the document's identity explicitly (options.Schema.For<Order>().Identity(x => x.Key)) and the default store does not;
• a strong-typed id, or StreamIdentity.AsString on one store and not the other;
• a type registered as a document on both stores with different id members.

Scope

Marten only. Polecat and Fisher reflect over the aggregate's Id property and consult no store at all (PolecatPersistenceFrameProvider.cs:33, FisherPersistenceFrameProvider.cs:33), so they have no store to be wrong about — though that is its own asymmetry worth noting.

What would close this

Either a failing test showing a handler on an ancillary store getting the wrong identity type, which turns this into a bug with the GH-4439 fix shape (read chain.AncillaryStoreType, fall back to the default store) — or a demonstration that Marten's per-store document configuration can never diverge in a way that reaches this call, in which case a comment saying so is the right outcome.

Refs GH-4439.

[jeremydmiller]

Investigated. This is a real bug, and it is wider than I filed it — the reproduction is [Entity], not [WriteModel].

Divergence is real

FindOrResolveDocumentType goes through Storage.FindMapping, which auto-creates a mapping by convention for a type the store has never been told about. So the default store never fails the question — it confidently invents an answer. A probe over two StoreOptions, no host and no database:

// ancillary store: o.Schema.For<SagaIdProbeOrder>().Identity(x => x.Code);
idTypeFor(main, typeof(SagaIdProbeOrder)).ShouldBe(typeof(Guid));      // never heard of the type
idTypeFor(ancillary, typeof(SagaIdProbeOrder)).ShouldBe(typeof(string)); // the store that holds it

Both pass. The two stores genuinely disagree.

And it reaches a handler

[MartenStore(typeof(ICodedOrderStore))]
public static class CodedOrderHandler
{
    public static void Handle(AddToCodedOrder command, [Entity("Code")] CodedOrder order, IDocumentSession session)
        => ...;
}

fails at codegen with:

Wolverine.Persistence.InvalidEntityLoadUsageException : Unable to determine a value variable named 'Code'
and source Anything to load an entity of type CodedOrder for parameter order

The command does carry Code. tryFindIdentityVariable passes idType into every lookup including the named-argument branch, so it searched for a Guid named Code and missed — because DetermineSagaIdType asked the default store, which answered Guid from the conventional Id property, while the store the handler actually commits through says string.

Correction to the original scope

Three call sites make the same chain-less call, so this is not [WriteModel]-only:

• EntityAttribute.cs:153 — the reproduction above
• ReadModelAttribute.cs:101
• WriteModelAttribute.cs:129

It remains Marten-only among the providers: Polecat and Fisher reflect over the Id property and consult no store at all, so they have no store to be wrong about.

Fix shape

Not a signature change — DetermineSagaIdType has 15 implementers (EF Core, RavenDb, CosmosDb, Redis, S3, Blob, Polecat, Fisher, the in-memory/lightweight providers and test doubles). Additive overload instead, following the existing TryDetermineTransactionOwnerType(IChain, IServiceContainer) => null precedent on the same interface, with Marten overriding it to consult chain.DetermineAncillaryStoreType() — the helper added in #4442.

That makes this dependent on #4442, so the PR will follow it rather than stack on it.