Very important to understand context.emit(event) in the Java SDK

We are enhancing the documentation for this. I spent the better part of yesterday chasing a race condition because I didn’t know that when you emit an event inside a command handler, the event handler callback happens concurrently and instantly. I was emitting somewhere in the middle of my code and was assuming my current state was stable throughout the command handler and it was not. Always emit at the bottom of the command handler, just before returning Empty etc.

Does anyone know if the JavaScript SDK behaves this way too?

According to Peter Vluger the answer is no if I’m understanding what he said here from a slack conversation:

" Note that applying event handlers immediately on emit is only in the Java SDK. The JavaScript SDK is different — it passes the current state as a parameter, and applies the events together after command handling to create a new state. So in JS, you end up applying these directly if needed for a response"

Right, this only applies to the Java SDK. The JavaScript SDK updates the local state after command handling.

We’re currently discussing these APIs and the Java SDK may become more similar to the JavaScript SDK: where the current state is fully managed and passed as a parameter (rather than kept in a variable in the entity object) and emitted events will be applied after (successful) command handling. To return an updated state, a thenReply or similar method could be provided, which takes the updated state and returns the response. This would be similar to the Akka Typed event sourced behaviour.

That is even an open issue over here for some time:

“Event sourcing – sequence of handling emitted events (JavaScript- vs. Java-Support)”

looking forward to get that merged back there too when changed.