| These docs don’t fill me with confidence. That’s… weird given who’s behind the project. What gives? > Workflows provide the following reliability guaranteees: > 1. They always run to completion. You can’t guarantee that. > 2 […] Regardless of what failures occur during a workflow's execution, it executes each of its transactions once and only once. “Executed” is the wrong word here, if the database goes down half way through a transaction it’s neither executed zero times nor once. > 3. Communicators execute at least once but are never re-executed after they successfully complete. If a failure occurs inside a communicator, the communicator may be retried That’s not what at-least-once means? In 2. “execute” means “run to completion” but here the logic only works if it means “try”. > Workflows must be deterministic: if called multiple times with the same inputs, they should always do the same thing. Deterministic is the wrong word here, the correct word is idempotent. e.g. A simple counting function is deterministic but not idempotent. |
For the last point, we'll clarify we mean that the code of the workflow function must be deterministic. For example, a workflow shouldn't make an HTTP GET request and use its result to determine what to do next, even though that's technically idempotent. Instead, it should make the HTTP request in a communicator (https://docs.dbos.dev/tutorials/communicator-tutorial) so its output can be saved and reused during recovery if necessary.