Archiving a stream in the same transaction as appending events to it leaves stream events unarchived

[AtomYcX]

When a stream fetched using optimistic concurrency via FetchForWriting<T> is archived using IDocumentSession.Events.ArchiveStream() any events that have been appended in the same transaction prior to calling ArchiveStream() remain with is_archived = false in the mt_events table, even though the stream itself is marked as archived in mt_streams.

Reproduction steps:

1. Fetch a stream using IDocumentSession.Events.FetchForWriting<T>
2. Append one or more events to the stream using IEventStream<T>.AppendMany
3. Archive the stream using IDocumentSession.Events.ArchiveStream
4. Commit the transaction using IDocumentSession.SaveChangesAsync

[Xzelsius]

Isn't this intended?
At least we thought so and use this behavior when we "hard-delete" something.

1. Append "hard delete" event to stream
2. Archive the same stream

this results in
"hard delete" event in unarchived state
all affected projections are run
stream itself and all previous events are archived

This allows us to rerun projection that have to delete data for the hard delete event.
But if the hard delete event is archived too, the event would be ignored during rebuilding the projection.

Once a day we cleanup archived streams from the database.

[jeremydmiller]

@Xzelsius There's a switch on most of the built in projections to utilize archived events in rebuilds. You shouldn't use it willy nilly, but it's there

[jeremydmiller]

@AtomYcX I'm going to address this by adding documentation to the effect that, yes, this is legal. @Xzelsius talked this over with me off to the side, and there is a valid use case for doing this. Maybe there could be a separate action for "archive all new events too"?

But also, what was your use case? Why did you both append and try to archive at the same time?

[tiagomsg]

Hi @jeremydmiller,

Our use case aligns with what @Xzelsius described above about "hard deleting" a stream.
We have some aggregates that we want to completely remove from projections and from any future rebuilds of those projections. Hence, we were appending a "deleted" event and archiving the stream.

Think the 1st question of #3258 more accurately describes our problem. Happy to close this in favor of it.