Similar to what we do today for IPersistentRepresentation et al.

Major changes needed:

• Remove ImmutableDictionary<T> in favor of Dictionary<T> - if the semantic isn't accessed concurrently, then it's not needed.
• Add ability to add single UnconfirmedDelivery messages to the AtLeastOnceDelivery state incrementally, so these items can be retrieved via Recover<UnconfirmedDelivery>.

Need to add an Akka.Persistence.IMessage type for a confirmed delivery which can be recovered during replay.

Apparently Akka.Persistence.Exras needs to be rebuilt with new Akka libraries. Running them with Akka.NET 1.5 causes the following error:

Method not found: 'Void Akka.Event.ILoggingAdapter.Error(System.String, System.Object[])'.

at Akka.Persistence.Extras.PersistenceSupervisor.OnTerminated(Object message)
at Akka.Persistence.Extras.PersistenceSupervisor.Receive(Object message)
at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
at Akka.Actor.ActorCell.ReceiveMessage(Object message)
at Akka.Actor.ActorCell.Invoke(Envelope envelope)

This is a showstopper for upgrading to Akka.NET 1.5 for those using PersistenceSupervisor.

Akka.Persistence.TestKit Requirements

This is an outline for an "Akka.Persistence.TestKit" NuGet package that can be used by Akka.NET developers to help test for possible errors that may come up in the course of using Akka.Persistence, such as:

1. Rejected messages due to serialization errors;
2. Write failures due to the journal or snapshot store being offline; and
3. Recovery errors as a result of serialization or connectivity issues.

These fake journal and snapshot store implementations should be programmable, so if we take a typical Arrange-Act-Assert pattern and factor our "FailingJournal" or "FailingSnapshotStore" into it:

public class MyTestKitClass : Akka.TestKit.Xunit2.Testkit{
	private readonly FailingJournal _failingJournal

	public MyTestKitClass() 
		: base(FailingJournal.DefaultConfig()) // need FailingJournal HOCON 
	{ 
		// need to grab an instance of the FailingJournal for programming purposes
		_failingJournal = PersistenceExt.Get(Sys);
	}

	public async Task MyFakeUnitTest(){
		// arrange
		var myPersistentActor = Sys.ActorOf(Props.Create(() => new MyPersistActor()), "p");
		myPersistentActor.Tell("write"); // write one message to journal while it's still working
		ExpectMsg("ack"); // message gets processed

		// terminate actor
		await myPersistentActor.GracefulStop();		

		// act

		await _failingJournal.BeginFailingWrites(); // simulate journal network disconnect		

		// assert
			
		// re-create a persistent actor - should fail
		EventFilter.Exception<RecoveryException>().ExpectOne(() => {
			var myPersistentActor2 = Sys.ActorOf(Props.Create(() => new MyPersistActor()), "p");
			
			// actor should stop as a result of recovery failure
			Watch(myPersistentActor);
			ExpectTerminated(myPersistentActor);
		});
	}
}

That's the general idea - make it easy to progam the behavior the journal and shapshot store in Akka.Persistence prior to actually using it.

Lexicon and Terminology

To make it easier to understand the requirements going forward, here are some technical terms we're going to use throuhout this document:

• FailingJournal - this is the journal that can be programmed to fail altogether or reject persistent messages.
• FailingSnapshotStore - same idea as the FailingJournal, but for the SnapshotStore.
• "Rejected message" - this means that the connection to the underlying journal is intact, but a specific message was rejected because it couldn't be serialized.
• "Failed message" - this means the message couldn't be written to the journal because the underlying datastore wasn't available due to a network partition.
• "Rejected snapshot" - same idea as "rejected message," but for the snapshot store.
• "Failed snapshot" - same idea as the "failed message," but for the snapshot store. Should trigger a SnapshotWriteFailure message.

Functional Requirements

The Akka.Persistence.TestKit package might eventually be released as an official part of Akka.NET, but for the time being, let's release the package as part of Akka.Persistence.Extras so we can avoid the inertia ivolved in making a new Akka.NET release as we're trying to get Akka.NET v1.4.0 shipped right now.

For the time being then, this package should be shipped as Akka.Persistence.Extras.TestKit.

This project should be built against Akka.Persistence v1.3.13.

FailingJournal and FailingSnapshotStore APIs

The FailingJournal and FailingSnapshotStore classes APIs must enable the end-user to do the following:

1. Toggle the journal/snapshot store's entire availability on and off - writes and recovers will both be rejected. If this method returns a Task, by the time that Task completes the toggle operation must have completed.
2. Toggle only the read or the write side of the journal/snapshot store's availability on and off - writes can be rejected but reads will succeed. If this method returns a Task, by the time that Task completes the toggle operation must have completed.
3. Set a filter on the journal/snapshot store to reject or fail messages (this should be a method parameter) on write or reead (should be a parameter) only if they match a certain predicate function specified by the end-user. That predicate will remain in-place on the journal or snapshot store until reset by the user. If this method returns a Task, by the time that Task completes the predicate must be securely in-place.
4. Unset all filters on the journal / snapshot store, if any were previously set by the end-user. If this method returns a Task, by the time that Task completes the toggle operation must have completed.

Enabling FailingJournal and FailingSnapshotStore inside an Akka.NET TestKit Test

The FailingJournal and the FailingSnapshotStore should wrap around the underlying MemoryJournal and MemorySnapshotStore and use them for underlying storage.

But in order to activate either one of these components inside a TestKit test, the end-user must pass in the embedded HOCON built into the FailingJournal.DefaultConfig() or FailingSnapshotStore.DefaultConfig() methods into the TestKit base class constructor, like this:

public class MyTestKitClass : Akka.TestKit.Xunit2.Testkit{
	private readonly FailingJournal _failingJournal

	public MyTestKitClass() 
		: base(FailingJournal.DefaultConfig()) // need FailingJournal HOCON 
	{ 
		// need to grab an instance of the FailingJournal for programming purposes
		_failingJournal = PersistenceExt.Get(Sys);
	}

	// tests
}

Testing Requirements

Need to cover all functional requirements with unit tests, in order to make sure that the API requirements are all met by the implementation. Expand as needed along with the API surface area.

If my persistent events all implement IConfirmable, maybe I don't need to specify a "make confirmable" delegate.

麻烦把国瑞的代码删除掉，谢谢

Allow the PersistenceSupervisor to pass itself into the childProps dynamically via invoking a function rather than hard-coding the props of the child - that way we don't have to rely on hard-coding the underlying PersistentActor to send confirmation messages back to its parent via Context.Parent.Tell, which seems brittle.

We should explain the motivation behind why the DeDuplicatingReceiveActor needs to persist its state in the first place.