Execution semantics
At-least-once execution, retries, timeouts and cancellation.
Intended behaviour
This page describes how Ongoings is designed to behave. Behaviour is confirmed with the Ongoings interface reference at release.
At least once, not exactly once
Ongoings executes work at least once. Progress is saved at checkpoints. If a worker stops or an attempt fails between checkpoints, the work after the last checkpoint runs again.
Ongoings does not promise that an external effect, such as charging a card or sending an email, happens exactly once.
Make side effects idempotent
Give each unit of work a stable key
For example, an order ID or a run ID plus step name.
Pass the key to the system you call
Use the target's idempotency key or deduplication feature where it has one.
Check before you act
If the effect already happened for that key, skip it.
Retries
Failed attempts can be retried. Each attempt is recorded, so you can see what failed and why.
Timeouts and cancellation
A timeout or cancellation stops Ongoings waiting for the work. It does not undo anything the work already did outside Ongoings. Check the target system before assuming an effect did not happen.
Dead letters (planned)
Ongoings is designed to set aside work that cannot be completed as a dead letter for inspection, instead of retrying forever. Dead-letter handling is planned and is not yet available. Until it is, do not depend on it in your design.