What guarantees to entities provide?

[ElanHasson]

Hi,

I am using v2- beta 3.

What guarantees do Entities provide?

1. When signaled by multiple processes, do they receive them in order and process one at a time? (Fire and Forget)

2. Is the state versioned?

3. How are retries handled?

Thanks

[sebastianburckhardt]

Here some preliminary answers. We likely need to make this a part of the official documentation as well.

1. We have logic to sort and deduplicate messages (signals & calls) arriving on entities. However, it does not apply to messages sent from clients. So, what we guarantee is:

• messages sent from orchestrations to entities are delivered effectively-once & in order

• messages sent from entities to entities are delivered effectively-once & in order

• messages sent from clients to entities are delivered at-least-once & possibly out of order

  The term 'effectively-once' means that the operation's effect on the entity state is "exactly-once", but the code may execute more than once if it is internally retried due to low-level failures (as defined below).

2. The state is not versioned by default. However, various forms of versioning can be achieved by controlling the details of the JSON serialization/deserialization process via Json.NET attributes. For example, one can add attributes to the user-defined type T when using either the function-based syntax GetState<T> or the class-based syntax DispatchAsync<T>.

3. Retry policy depends on the type of failure. Here is a bit of discussion.

• Low-level failures: If machine, network, or storage fail in some way, it is possible for a entity operation to "fail" in the sense that it does not execute successfully all the way and persist to storage. In that case, no changes to the entity state are saved, no outbound messages are sent, and the operation is retried.
• Application-level failures: Exceptions thrown while executing an entity operation are considered application-level and are not retried - rather, they are considered 'the result' of the operation, just like for tasks in TPL. They are also rethrown in the calling orchestration, where applicable. This type of failure includes deserialization exceptions encountered while reading storage or inputs, and serialization exceptions encountered while sending messages.

[ElanHasson]

Thanks for the info @sebastianburckhardt !

I'll let you know if I have additional questions after I digest this a bit more :)