Allow ReadModels Marked For Deletion To Be "Unmarked" for Deletion

[WardenUnleashed]

My team is currently developing some functionality where we will "deleting" multiple aggregates within a Saga. In the case that a step within the Saga fails, we add a compensating "restore" event to essentially undelete it.

This works fine for Aggregates as we have a simple IsDeleted boolean.
However, when we try to update the read model's we start to run into a problem. Ideally we would like to avoid adding a IsDeleted property on our read model and instead mark the model for deletion via the context(making it easier to query the read models in the future).

However, it would appear that once you mark the Read Model Context for deletion, you can't unset it.

I would like to suggest this as a feature.

Additionally, provided this is something that would be acceptable to change; I would be willing to implement it to reduce the bandwidth on maintainers.

[github-actions]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days.
We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards,
EventFlow

[github-actions]

Hello there!

We hope you are doing well. We noticed that this issue has not seen any activity in the past 90 days.
We consider this issue to be stale and will be closing it within the next seven days.

If you still require assistance with this issue, please feel free to reopen it or create a new issue.

Thank you for your understanding and cooperation.

Best regards,
EventFlow

[rasmus]

@WardenUnleashed if I read you right, you are merely asking for a UnmarkForDeletion() on the IReadModelContext or maybe simply make the setter for IsMarkedForDeletion public?

[rasmus]

.analyze

[github-actions]

Key Findings

• ReadModelContext only ever flips IsMarkedForDeletion to true; there is no API to revert it, so once a read model calls context.MarkForDeletion() it cannot change its mind inside the same update pipeline (Source/EventFlow/ReadStores/ReadModelContext.cs:29).
• The interface surface mirrors that limitation: IReadModelContext exposes only MarkForDeletion() plus the read-only flag, preventing custom context implementations from offering an “undo” (Source/EventFlow/ReadStores/IReadModelContext.cs:30).
• Every read-store implementation inspects the flag only after all domain events have been applied; if the flag is true the backing record is removed (Source/EventFlow/ReadStores/InMemory/InMemoryReadStore.cs:123, same pattern in SQL, MongoDB, Redis, Elasticsearch, etc.). With the current API, once any handler marks for deletion the store will permanently drop the read model.
• Because deletions remove the persisted read-model envelope (including its version), subsequent events for that aggregate start from an empty envelope (Source/EventFlow/ReadStores/ReadModelEnvelope.cs:57). Combined with the version checks in SingleAggregateReadStoreManager, a restore/compensating event will be replayed on a brand-new instance and will not automatically rehydrate historic state unless the restore event itself carries the full data (Source/EventFlow/ReadStores/SingleAggregateReadStoreManager.cs:145).

Reproduction

• Implement a read model that handles DeletedEvent by calling context.MarkForDeletion() and a compensating RestoredEvent that should keep the row.
• Attempting to “unmark” in RestoredEvent is impossible: there is no method to invoke and the flag cannot be set back to false, so the read store deletes the record after the batch no matter what.
• Even if you delay deletion (e.g., swallowing MarkForDeletion()), once a deletion was processed in an earlier batch the record and version are gone, leaving later restore events without the historic state.

Proposed Direction

• Extend IReadModelContext with a reversible API (e.g., void PreventDeletion() / void ClearDeletionMark() or a general void SetDeletionStatus(bool shouldDelete)), and implement it in ReadModelContext by toggling the backing flag.
• Update all read-store implementations to continue relying on the final flag value; no behavioral change required there, but new tests should verify that a delete followed by an “undo” within the same update leaves the record intact.
• Document the behavior so developers understand the distinction between cancelling a pending deletion within a single event batch versus resurrecting a model that was already deleted in a previous batch. The latter still needs either a repopulation or a restore event rich enough to rebuild the read model.

Considerations

• Adding a new member to IReadModelContext is a binary-breaking change for anyone shipping their own context implementation; the feature should therefore target a major/minor release that allows such API evolution, and release notes should call out the required implementation update.
• Because EventFlow 1.x targets modern TFMs, default interface methods could provide a non-breaking shim, but that would leak undesired semantics (the default implementation cannot toggle the backing state). A straight interface addition keeps semantics explicit.
• Even with the API in place, teams that rely on read-model deletion for permanent removal should be cautious: undoing a deletion mid-batch keeps the record, but restoring after the deletion went through still needs a broader repopulation strategy.

Your friendly neighborhood AI