Lift IEventDataMasking into JasperFx.Events.Protected, then an event data masking compliance suite

[jeremydmiller]

Part of #5118 (compliance wave growth), epic #5110. Cross-repo: the first half targets jasperfx.

Event data masking — rewriting protected information inside already-stored events, for GDPR-style erasure — is implemented in both products with the same shape and the same member names, in parallel namespaces:

Marten	Marten/Events/Protected/EventDataMasking.cs:111 — interface IEventDataMasking; Advanced.ApplyEventDataMasking(Action<IEventDataMasking>, ct) (AdvancedOperations.cs:837); EventGraph.AddMaskingRuleForProtectedInformation<T>(...)
Polecat	Polecat/Events/Protected/EventDataMasking.cs:11 — interface IEventDataMasking with ForTenant(string); Advanced.ApplyEventDataMasking(...) (AdvancedOperations.cs:592); EventGraph.AddMaskingRuleForProtectedInformation<T> (EventGraph.cs:639,649)
jasperfx	nothing — but JasperFx.Events/Protected/ already exists and owns StreamCompactingRequest<T>

Two independent copies of the same interface in a folder whose shared sibling already lives upstream. This is the clearest remaining upstream lift in the event store surface.

Part 1 (jasperfx): lift IEventDataMasking

Move IEventDataMasking (and the masking-rule registration on the event registry) into JasperFx.Events.Protected, with both products' current members reconciled — note Polecat's ForTenant(string tenantId) has no Marten counterpart, so decide whether it is part of the shared contract or a Polecat extension before lifting. Both products then delete their copy and re-export.

Part 2 (compliance): the suite

EventDataMaskingCompliance, needing one seam member — EventStoreComplianceFixture.ApplyEventDataMaskingAsync(Action<IEventDataMasking>), since Advanced is each product's own type — plus a config entry for the masking rules.

Marten tests today	Polecat tests today
protecting_sensitive_data.cs	Events/event_data_masking_tests.cs
removing_protected_information.cs

1. A masking rule rewrites the stored event body for the matched events only
2. Masking is idempotent — applying twice does not corrupt
3. Masked events keep their sequence, version, timestamp and type name
4. Masking by stream, by event type, and by a predicate over the event
5. An inline snapshot built before masking is not silently changed (settle the intended behavior — a rebuild is the documented way to propagate)
6. ForTenant scoping if it survives the lift as shared

Acceptance

• jasperfx: interface lifted, JasperFxVersion bumped in the same PR, both products adopt and delete their copies
• One fixture member + one config entry; suite enrolled in both stores
• Originals retired in both repos

[jeremydmiller]

First half done — the lift merged in #635, publishing as 2.41.0

IEventDataMasking into JasperFx.Events/Protected/. The two copies turned out member-for-member identical — ForTenant, four IncludeStream overloads, IncludeEvents(Expression<Func<IEvent,bool>>), AddHeader, same order, same signatures. It sits beside StreamCompactingRequest<T> for the same reason: the request shape is a database-agnostic description of intent, while executing it is unavoidably store-specific.

Adoption is a straight swap — both products delete their copy and use the shared interface. Non-breaking in practice for their users, since the common usage (Advanced.ApplyEventDataMasking(x => x.IncludeStream(...))) never names the type.

Still outstanding on this issue

The compliance suite this lift exists to enable. That is the second half of the issue's scope and is not built yet — it needs the consumers on 2.41.0 first, since the suite has to call the lifted member through the shared interface.

Leaving this open until the suite ships and is enrolled in both stores.

[jeremydmiller]

Second half built — EventDataMaskingCompliance, 10 tests, in #639 (2.43.0)

And this issue's premise needs correcting. The earlier comment said the lift makes masking reachable; it does not.

Lifting IEventDataMasking made the vocabulary shared, not the reach. Both products hand one out through Advanced.ApplyEventDataMasking(Action<IEventDataMasking>, CancellationToken) on store-specific advanced-operations types that share no interface, and both register rules through their own event options (Events.AddMaskingRuleForProtectedInformation<T>, identical signatures on both, on no shared interface).

So the suite costs three seam members, not zero:

• EventStoreComplianceFixture.ApplyEventDataMaskingAsync(Action<IEventDataMasking>, CancellationToken) — deliberately not "give me the store's advanced operations", which would drag an unbounded product surface into the seam
• ComplianceStoreConfig.AddMaskingRule<TEvent>(Action<TEvent>) and AddMaskingRule<TEvent>(Func<TEvent, TEvent>) — both forms, because the functional one is the only thing a record with init-only members can use

That does not make the lift wasted — the suite still names one shared interface rather than two parallel ones — but it does mean this belonged in the "needs a seam addition" group all along rather than the upstream-lift group.

⚠️ The suite found a real bug in both products, first try

EventGraph.TryMask ran its maskers as matched = matched || masker.TryMask(e). || short-circuits, so the first rule to match an event stopped every later rule from being invoked — while the operation still reported success. On a right-to-erasure path that leaves protected information in the database after a masking pass that looked like it worked.

Byte-identical in both repos, so two fixes: marten#5199 / #5200 and polecat#422.

Nothing caught it before because every masking test in both repos registers rules over disjoint event types, so no event ever matched two rules and the short-circuit was unobservable.

Coverage

Rules composing, contravariant matching through an interface, the replacing (Func<T,T>) form against a record, event types with no rule left alone, streams not included left alone, the stream-level filter predicate, headers landing on masked events only, no change to event count or stream version, and the string-identified stream.

Deliberately not asserted: what an empty masking request does. One product's own tests pin it as throwing and nothing documents that as a cross-store contract, so encoding it would pin an implementation detail rather than a promise — the same trap the FetchLatest suite hit over uncommitted appends.

Marten: 10/10. Closes when both consumers have enrolled it.