Execution Guarantees of Activities

I’m wondering about the delivery / execution guarantees and semantics of temporal task queues.

Temporal talks about using “task queues” a lot in the documentation. Normally when we talk about queues, we also talk about delivery guarantees and semantics. Systems can have “at most once”, “at least once” and “exactly once” semantics. My question is which one of these do temporal queues fall under? This has a big effect on how we code activities.

If the activity is executed “at least once” then all activities must be coded in an idempotent way, where they expect they may be called more than once.

If the activity is executed “at most once” then the activity may not run and the system is not very useful in general.

If the activity is executed exactly once, then it would be possible to relax the idempotency of the activity logic, if we can safely rely on temporal to guarantee this.

This same question of course applies to workflow execution and child-workflow execution.

Thanks in advance for any insight!

Temporal activity in a single cluster setup is executed at least once by default as it has an associated default retry policy.

If the retry options maximumAttempts is equal to 1 then the activity is executed at most once.

If the activity is executed “at most once” then the activity may not run and the system is not very useful in general.

This is not really true as in the case of Temporal as a workflow is guaranteed to get an error if an activity failed to execute. So workflow can take some compensating actions if necessary.

This same question of course applies to workflow execution and child-workflow execution.

A workflow is guaranteed to be executed exactly once unless it failes and is retried. Note that a workflow doesn’t have a default retry policy.

A child workflow is guaranteed to execute exactly once unless it fails and is retried as it is just a workflow.

Deleted my first reply because I didn’t understand what you said at first.

This is helpful though, thank you!

It would be great to have a section on this in the docs, sort of like rabbitmq’s reliability guide.