Thanks for the pull request, this looks like a good start.

It’s worth noting that events published to subscribers, such as event handlers and process managers, won’t go through the stream forward function. To solve this issue the Commanded.EventStore behaviour will need to be extended to allow a mapper function to be provided to both stream forward and subscribe to stream so that the upcasting can happen in both places. This likely requires changes to the in-memory adapter, Postgres event store adapter, and Greg Young’s Event Store (extreme) adapter. There’s quite a lot of coordination involved in changing all three of those so unless you’re feeling brave I can merge this PR as is and continue?

Thanks Ben. Good catch. I'd like to investigate this further before you merge it.

I think the latest commit addresses your concerns and will not required tweaking on the ES adapters.

As I believe this is commanded only feature, we should be good.

Oh! And I fixed a bug in the InMemory adapter. It was enuming over the stream and therefore executing the event_stream.

And apparently this broke some tests. :)

Fixing....

I wonder if stream_forward is the right place for the upcast. I'm thinking it should really be in Aggregate.handle_info({:events, events}, _) like the others.

Thoughts?

Aggregate.handle_info({:events, events}, _)

Is only used for transient subscriptions to the configured event store which means it will never receive historical events so no upcasting is required.

Having the upcast applied in stream_forward is useful because it allows consumers to read from the configured event store if they need to.

@trbngr Is this PR ready to merge now?

That's your call, bud. I am done with it