Levi Ramsey

It is possible to MacGyver this functionality (modulo what event deletion actually entails in your persistence plugin) with a `Tombstoned` event and a `ForceSnapshot` command/`SnapshotForced` event pair. For an entity...

Actually, that approach won't quite work, but an elaboration of that will: force a tombstone check before building the `EventSourcedBehavior` and if that comes back "tombstoned", then the `EventSourcedBehavior` gets...

`SnapshotStore.doDeleteAsync` wouldn't necessarily be hit when deleting events. That would be the journal plugin's `asyncDeleteMessagesTo` method. Snapshot deletion in `withDeleteEventsOnSnapshot` only happens if events are successfully deleted.

Since `messageAdapter` requires a total function, an adapter which doesn't match the incoming message would have to throw, which (since the adaptation runs inside the actor) would crash the actor.

One could probably define an `Ordering[Class[_]]` based on assignability with something like: ```scala // only mentally compiled... new Ordering[Class[_]] { def compare(x: Class[_], y: Class[_]): Int = { val xAssignableToY...

I know at a `$PREVIOUS_EMPLOYER` we implemented similar functionality, so there's definitely some demand. At minimum maybe this goes into `akka-stream-contrib`? I do wonder if there needs to be a...

The only benefit I can see is in a metric-tickling case where you're OK with sometimes not tickling the metric ("high-volume random sampling"...) and also want to limit the number...

Yeah, I bounced between unpersistent and nonpersistent... `NotPersistent` could also be an option.

One bit of functionality that's not implemented yet is the `lastSequenceNumber`. The easiest way to do that could be to have the unpersistent and persistent versions extend a `HasSequenceNumber` trait...

Okay, hadn't noticed that @johanandren