Resumability
Runs are resumable by returning Task stored data
Runs can exceed the maximum timeout on serverless platforms and can survive server restarts.
How does this work?
- When a Run is created, it is given a unique ID. This ID is used to identify the Run.
- Tasks have a
cacheKey
which is a string and is the first parameter. This should be stable and unique inside thatrun
function. - When a Task is completed, its output is stored.
- If a Run exceeds the timeout, or your server restarts, the Run will be “replayed”.
- The second+ time it is run, Tasks that have already successfully completed will immediately return their first output. The code inside them won’t re-run.
How to use cache keys
Like we mentioned above, we use Task cache keys to determine which Tasks have already been executed. They are defined by you inside your run
function, for example when you call io.slack.postMessage
:
In this example, the cache key is the string "⭐️ New Star"
. This means that if the Job is interrupted and then resumed, the slack.postMessage
Task will be skipped because it has already been executed.
If you make multiple calls to slack.postMessage
, you should use different cache keys for each call. For example:
If you are calling a Task multiple times with the same key, it will only be executed once. For example, if you call slack.postMessage
with the key "⭐️ New Star"
twice, it will only be executed once.
See our Task concept guide for more information about tasks and how they are crucial to the resumability of your Jobs.
How to use cache keys with loops
If you are using a loop, you should use the loop index as the key. For example:
We don’t currently support running tasks in parallel so Promise.all
will not work correctly.
This is something on our roadmap that we hope to support soon.
Was this page helpful?