Pre-populate chain.AncillaryStoreType in Phase A so the inbox-routing map sees [MartenStore] (closes #2944)

[jeremydmiller]

Closes #2944. Reported by @fadrian23.

The bug

A message arriving from an external system in interop mode (raw JSON, no Wolverine envelope headers) whose handler targets an ancillary Marten store via [MartenStore] had its durable-inbox envelope persisted in the main store's inbox instead of the ancillary store's. The handler still ran (Wolverine's message routing finds the chain fine), but the inbox row landed in the wrong place — so the reporter's downstream operational assertions about ancillary-store atomicity broke.

The reporter pinpointed the exact line in their issue:

// WolverineRuntime.HostService.cs:447
foreach (var chain in Handlers.AllChains().Where(c => c.AncillaryStoreType != null))

returns 0 records, because chain.AncillaryStoreType is still null at that point.

Root cause

Same Phase A vs Phase B ordering trap as GH-2941:

• [MartenStore] derives from ModifyChainAttribute. MartenStoreAttribute.Modify() runs in Phase B (lazy, inside HandlerChain.applyCustomizations at first-codegen time).
• The map that WolverineRuntime.HostService builds during startMessagingTransportsAsync runs in Phase A (eager, at handler-graph compile).

At the time of the Phase A loop, no chain has had its applyCustomizations triggered yet — so chain.AncillaryStoreType is null on every chain and the map is built empty. When an interop message arrives, DurableLocalQueue / DurableReceiver calls Stores.TryFindAncillaryStoreForMessageType(envelope.MessageType), hits an empty map, and falls back to the main store.

The prior fix at HostService.cs:447 (AllChains() over Chains, GH-2576) addressed per-endpoint sticky chains under MultipleHandlerBehavior.Separated — but didn't address the ordering trap. By the time it runs, the chains still have null AncillaryStoreType.

Fix

A new internal MartenStoreEagerPolicy : IHandlerPolicy in Wolverine.Marten, registered by MartenIntegration alongside MartenAggregateHandlerStrategy. It runs in Phase A and pre-populates chain.AncillaryStoreType by walking each HandlerChain's handler-type and handler-method for [MartenStore] — matching the discovery rules already used in Chain.applyAttributesAndConfigureMethods (handler-type + handler-method). Also walks the per-endpoint sticky child chains (ByEndpoint) so Separated-mode keeps working alongside #2576.

The Phase B MartenStoreAttribute.Modify() still runs later — the AncillaryStoreType reassignment is idempotent, and the AncillaryOutboxFactoryFrame middleware insertion stays where it has to be (it participates in codegen).

Tests + verification

New regression: Bug_2944_interop_ancillary_inbox in Wolverine.RabbitMQ.Tests/Bugs/ mirrors the reporter's repro — publishes a raw JSON message (no Wolverine headers) to a durable RabbitMQ queue whose default incoming type has a [MartenStore]-decorated handler, then asserts the inbox envelope landed in the ancillary store and not the main store.

Suite	Result
Bug_2944_interop_ancillary_inbox (new)	1/1 pass
Marten ancillary + bug-family (AncillaryStores + Bug_2318 + Bug_2382 + Bug_2576 + Bug_2669 + Bug_2887 + Bug_ancillary + Distribution.with_ancillary)	30/30 pass
EfCoreTests.Bug_DurableLocalQueue_ancillary	3/3 pass
Wolverine.RabbitMQ.Tests.Bug_2155_ancillary	1/1 pass
Wolverine.Http.Tests.using_ancillary_stores	1/1 pass
Full Marten Bugs	45/45 pass
Full AggregateHandlerWorkflow	66/66 pass
dotnet build wolverine.slnx -c Release	0 warnings, 0 errors

Negative-control: commenting out the policy registration makes Bug_2944_interop_ancillary_inbox fail with exactly the assertion the reporter described — "The interop message should have been persisted in the ancillary store's inbox" — confirming the test exercises the bug.

PersistenceTests.ModularMonoliths.end_to_end_modular_monolith and .registration_of_message_stores could not be validated locally — their SQL-Server-touching fixtures time out under emulated SQL Server 2025 on Apple Silicon. The same tests fail the same way on the baseline (no fix) — this is a pre-existing local-environment limitation, not a regression introduced here. CI on native Linux SQL Server validates them.

🤖 Generated with Claude Code