search

akka / akka-edge-rs

Akka Edge support in Rust
https://doc.akka.io/docs/akka-edge/current/
Other
9 stars 1 forks source link

Difference in consistency boundary from regular Akka #106

Closed johanandren closed 1 year ago

johanandren commented 1 year ago

In Akka Persistence the only the first effect is allowed to be a persist, and there is no direct API to do something async after receiving a command that then leads to a persist once that async task completes. This is on purpose since validating a command against the state and then persisting an event will always be inside a consistency boundary.

If the command can trigger some async logic and then persist an event once it completes, the state may have changed in the meanwhile, breaking the boundary making it possible to persist events that are not valid given the current state.

In the effect API here I think it is possible to do for example emit_event, and_then/and(then( some async work, followed by a and_then_emit_event which will break the boundary.

If we want to leave that up to the user to make sure they don't shoot their own feed, we should carefully document this difference.

huntc commented 1 year ago

I may not fully understand yet, but a chain of effects for a given entity id must complete before any further commands are processed for that same entity id.

huntc commented 1 year ago

If the command can trigger some async logic and then persist an event once it completes, the state may have changed in the meanwhile, breaking the boundary making it possible to persist events that are not valid given the current state.

Just to be clear... this cannot happen as per my comment above.

huntc commented 1 year ago

Looking also at the API documentation, the statements above are not apparent there. I should correct that.

johanandren commented 1 year ago

Ah, ok, I thought you might end up with mixed async logic from a subsequent command, but they are in fact held off until the chain of effects completes, then I think we are good. But extra clarifification in docs seems good as it is different from JVM Akka Persistence.

patriknw commented 1 year ago

I agree that this should be fine as long as we don't process next command until everything finished for previous command. That is something we might want in the JVM behavior as well, we have talked about the need for async validation but so far deferred that to user code with stashing.

huntc commented 1 year ago

Does the additional doc now resolve this?

johanandren commented 1 year ago

Good enough IMO