Willem Peters

I would not prefer to use the actual aggregate to get the information you need. Either the event should contain the data you need or you could build up readmodels...

My team is also looking into situation's like this and I believe it would be pretty hard to ensure for every possible crash situation. Would using asynchronous subscribers not loose...

Persistence of the event and the transaction log would then to have be in the same logical commit right? And you would need to extend the existing eventstore implementations to...

Are there still plans to do something with this issue? We are going to create something for this as well. When we have a concept ready I wil update this...

we are working on it internally but have it is not ready yet. At the moment we are working on being able to recover from crashing anywhere within the process...

@rasmus so far it seems more likely that we have to replace the existing one. It also is not only in the DomainEventPublisher but also the IDispatchToSagas and IDispatchToSubscribers implementation....

Sadly we still have not continued work on it. But if we do not get to in soon I will make time for it

We have a maybe a another use case in combination with sagas. Right now we sometimes use direct updates on the sagas using the new method you expose on the...

I am quit suprised that someone is still using this :). You are converting to project.json format even though that is also deprecated by now?

I am currently trying without opensession but with only direct Invoke-commands .This seems to be much more stable. As in no extra exit statements are needed. Currently i use executeScript...