Polecat primary IEventStore bridge registers twice — GetServices<IEventStore>() yields the same DocumentStore instance two times

[jeremydmiller]

Small one, found writing the CritterWatch pin test for #3219 (whose ancillary fix works as designed).

A minimal Solo host:

opts.Services.AddPolecat(m => { ... }).IntegrateWithWolverine();
opts.Services.AddPolecatStore<ICritterWatchStore>(m => { ... }).IntegrateWithWolverine();

yields THREE IEventStore registrations — the primary Polecat.DocumentStore appears twice (reference-equal, same hash), plus the ancillary once:

Polecat.DocumentStore          hash=66385004
Polecat.DocumentStore          hash=66385004   ← duplicate
ICritterWatchStoreImplementation hash=14267127

Impact is minor but real for anything iterating GetServices<IEventStore>(): CritterWatch's EventProgressionPoller polls the primary store twice per pass (duplicate progression reads + duplicate snapshots posted), and duplicate-sensitive counts (stores.Count) are off by one. Wolverine.Polecat 6.17.1, Polecat 4.8.0.

Likely the WolverineOptionsPolecatExtensions primary bridge (AddSingleton<IEventStore>(s => (IEventStore)s.GetRequiredService<IDocumentStore>())) executing twice — once from the explicit IntegrateWithWolverine() and once from an internal integration pass. TryAdd-style registration (or an enumerable-dedupe) would fix it either way.

[jeremydmiller]

My guessed root cause in the issue was wrong, and the real one is more interesting. Fixed in #3412.

Not what I said

I speculated that IntegrateWithWolverine() was executing twice — once explicitly, once via an internal integration pass. It isn't. It runs exactly once. Dumping the IServiceCollection descriptors for the exact host shape from the issue shows what's really there:

IEventStore -> Polecat.PolecatServiceCollectionExtensions+<>c.<AddPolecat>b__3_4                        <-- Polecat's own
IEventStore -> Wolverine.Polecat.WolverineOptionsPolecatExtensions+<>c.<IntegrateWithWolverine>b__0_3   <-- ours, redundant
IEventStore -> Wolverine.Polecat.AncillaryWolverineOptionsPolecatExtensions+<>c__0`1[IPlayerStore]...

Two different registration sites, each running once. Polecat's own AddPolecat() already registers JasperFx.Events.IEventStore for the primary DocumentStore, and Wolverine bridged it a second time at WolverineOptionsPolecatExtensions.cs:116. Both factories resolve the same IDocumentStore singleton, hence the reference-equal duplicate.

Why it went unnoticed

Wolverine's bridge was correct when it was added (GH-3133 / GH-3219) — AddPolecat genuinely did not register IEventStore at the time. Polecat later started doing so, and the two silently stacked. What kept it invisible is the code comment sitting right above our registration:

// Polecat's AddPolecat registers IDocumentStore but not the store-agnostic IEventStore

which stopped being true and nobody re-checked it. A stale comment asserting the exact precondition that had quietly changed.

The fix

Delete the redundant primary bridge. That restores parity with Wolverine.Marten, which registers nothing equivalent for its primary store precisely because AddMarten handles it. The ancillary bridge stays — AddPolecatStore<T>() does not register IEventStore for the T store, so that one is still load-bearing.

Verified the redundancy is unconditional rather than config-dependent: Polecat registers IEventStore on all four AddPolecat overloads (Action<StoreOptions>, string, StoreOptions, Func<IServiceProvider, StoreOptions>) at 4.8.0, which is the floor of our package range [4.8.0,6.0.0) and the version NuGet actually resolves. So deleting our bridge is safe across the whole supported range.

Also worth recording: TryAddEnumerable is not usable here (it was my other suggestion). It throws when a descriptor's implementation type equals its service type, which is exactly the case for an AddSingleton<IEventStore>(sp => ...) factory registration on both sides.

Regression test asserts reference-distinctness, not just a count: all resolved stores distinct by reference, primary exactly once, ancillary exactly once.