Unwrap Nullable<T> when determining a Polecat aggregate's id type (GH-3942)

[jeremydmiller]

Closes #3942.

WriteModelAttribute.Modify asks the persistence provider for the aggregate's id type, and FindIdentity then branches on whether that answer is primitive. The two stores disagreed for a nullable id property:

store	answer for an aggregate whose Id is AlertId? (a strong-typed record struct)
Marten	the configured document id type — string there (StreamIdentity.AsString)
Polecat	sagaType.GetProperty("Id").PropertyType verbatim → Nullable<AlertId>

Nullable<AlertId> is not primitive, so IsPrimitiveIdType was false, the documented IdentifiedBy<T> escape hatch was skipped entirely, and the message was scanned for a Nullable<AlertId> member — which exists in no codebase. The result was InvalidOperationException: Unable to determine an aggregate id, naming neither the type nor nullability.

That broke every [WriteModel] chain over such an aggregate in the Polecat/SQL Server flavour, while the identical shared source compiled and ran fine under Marten.

Change

Both reflection sites now unwrap, exactly as the issue suggested:

var idProp = sagaType.GetProperty("Id", BindingFlags.Public | BindingFlags.Instance);
if (idProp == null) return typeof(Guid);
return Nullable.GetUnderlyingType(idProp.PropertyType) ?? idProp.PropertyType;

• PolecatPersistenceFrameProvider.DetermineSagaIdType
• DocumentExistsAttribute.ResolveIdType, whose doc comment already declared it matches the former — so they stay in lockstep

Nothing else changes: a non-nullable id, a string id, and a missing Id property all resolve exactly as before.

Verification

New Bugs/Bug_3942_nullable_aggregate_id_type.cs — 7 tests, 3 of which fail without this change (the two nullable cases on the saga provider, plus the document-resolution lockstep test). The rest pin that the untouched cases stay untouched.

These are deliberately reflection-level rather than integration tests. The failure is at codegen time, and under TypeLoadMode.Dynamic a chain only fails when its message first arrives — so an integration test would have to dispatch every message type to see it, which is why it took a codegen sweep across both flavours to surface at all.

Note string? erases to string at runtime, which is precisely why this only ever bit value-type ids; there is a test pinning that too.

🤖 Generated with Claude Code

https://claude.ai/code/session_014PwvC24c5dNxv7DJR7RUjv