EventProjectionScenario's wipe covers composite projections (#5169)

[jeremydmiller]

Closes #5169.

The bug

ProjectionScenario.DeleteExistingDataAsync built its wipe list from Options.StorageTypes:

await _store.Advanced.Clean.DeleteAllEventDataAsync(ct);
foreach (var storageType in _store.Options.Projections.All.SelectMany(x => x.Options.StorageTypes))
{
    await _store.Advanced.Clean.DeleteDocumentsByTypeAsync(storageType, ct);
}

A CompositeProjection never populates its own Options.StorageTypes (nor CleanUps) — its members hold theirs. So for a store whose read side is one composite over ~10 members, the loop iterated nothing. Event data was deleted, the composite's read models were not, and every scenario after the first ran against the previous scenario's documents while their events were gone. Because the events were deleted, nothing downstream could reconstruct or even notice the leftovers.

Tests stayed accidentally correct as long as they used unique ids per scenario. Any unfiltered Query<T>() inside AssertAgainstProjectedData saw prior scenarios' rows — which is how the reporter hit it: an ordered Query<InvoiceOverviewItem>() asserting [100m, 200m] returned [90m, 100m, 100m, 200m, 250m].

The fix

The wipe walks PublishedTypes() instead:

foreach (var storageType in _store.Options.Projections.All.SelectMany(x => x.PublishedTypes()).Distinct())

That is the right traversal for three independent reasons:

• CompositeProjection<,>.PublishedTypes() already unions its stages' members, so composites expand correctly with no new machinery;
• it is a superset of Options.StorageTypes for every ProjectionBase (PublishedTypes() = _publishedTypes ∪ Options.StorageTypes), so nothing that was wiped before stops being wiped;
• it is what Marten's own schema build-out uses (StorageFeatures → AllPublishedTypes()), whereas StorageTypes is documented as a schema-building hint — "used to help build out schema objects if the async daemon is started before the rest of the application" — not a teardown list.

That covers the issue's suggested fix 1. Fix 2 (having the composite populate its own StorageTypes/CleanUps from its members) is deliberately not taken: duplicating the members' CleanUps onto the parent would make the rebuild teardown in #5175 truncate every member table twice, and the schema-build concern it was meant to address is already handled by PublishedTypes().

Tests

DaemonTests/EventProjections/Bug_5169_composite_scenario_wipe.cs:

• the_composite_reports_the_document_types_its_members_write — the composite's PublishedTypes() carries both a stage-1 snapshot type and a stage-2 read model, and its Options.StorageTypes is empty (documenting why the old source could not work)
• a_second_scenario_starts_from_a_clean_slate — the issue's repro: two sequential EventProjectionScenario runs over a composite; the second must see exactly one invoice and one overview, and the first scenario's documents must be gone

Falsified: reverting the one-line change makes a_second_scenario_starts_from_a_clean_slate fail. All 26 EventProjections + Bug_5169 tests pass on net10.0.

Adjacent to #5175, which is the same family (a composite's members being invisible from the outside) but a different mechanism — rebuild teardown reading each member's CleanUps.

🤖 Generated with Claude Code

https://claude.ai/code/session_017CTtw2kVRSZKp1p5RTxgAy