Task Library
These are the built-in tasks that are available to use in your Jobs.
Welcome to the Trigger.dev Task Library π. You may be wondering, what is a Task and why are there a library of them? Well you see, Trigger.dev works by divvying up a long-running job execution into a bunch of little tasks, each one taking less time then a single serverless function execution. π«
You can define and run your own tasks easily using io.runTask(), or you can use one of our Integrations which are tasks for specific APIs, like OpenAI or Stripe.
We also have a growing library of built-in tasks that you can use in your Jobs through the io
object. These tasks are designed to be generic and reusable, and are a great way to get started with Trigger.dev.
You may notice that Iβm using emojis for all the cache keys below, which is totally π―% fine as long as they are unique inside a run. Read more about how cache keys work here
wait
This task allows you to resume executing your job after a certain amount of time has passed:
Internally this task is considered a βnoopβ, and noop tasks have no output.
waitForRequest
You supply this task with a callback to receive a URL. When a POST request is made to that URL, the JSON body of the request becomes the task output.
The example below uses waitForRequest
to capture a Screenshot of a website using ScreenshotOne.com and passes the callback URL to the webhook URL to get notified when the screenshot is finished:
We actually originally built this task for our Replicate integration, which accepts a callback URL to notify you when a prediction is ready. So this allows you to write very succinct code to create a prediction and wait for itβs results:
waitForEvent
This task allows you to wait for an event to be sent. To read about how events work, check out the Events documentation.
The event object returned from this task is the full event object that was sent, including id
, name
, payload
, context
, and more.
backgroundFetch
This task allows you to perform a fetch
request in the background, and then resume the execution of your job after the request has completed.
This is useful for when an API is slow to respond and might not finish before your serverless function times out. We created this task to power our OpenAI integration, which can sometimes take more than a minute to respond:
backgroundPoll
This task is similar to backgroundFetch
, but instead of waiting for a single request to complete, it will poll a URL until it returns a certain value.
logger
The logger object allows you to log messages to the Trigger.dev console. This is useful for debugging your jobs, or just to see whatβs going on inside your job.
You can optionally pass a context
object to the logger, which will be displayed in the console:
We support the following log levels:
io.logger.debug()
io.logger.info()
io.logger.warn()
io.logger.error()
You may notice these tasks donβt include cache keys. We automatically create a cache key for you based on the message and the log-level
store
The store object exposes several namespaced Key-Value Stores you can access inside of your Jobs. This is useful for storing small amounts of serializable data for later retrieval:
If you want to access the store from outside a run (e.g. just from your backend) you should use client.store instead.
The following namespaces are at your disposal:
store.env
to access and store data within the Environmentstore.job
to access and store data within the Jobstore.run
to access and store data within the Run
random
Use this task to generate a random number that stays stable during run retries/resumes:
sendEvent
This task allows you to send an event from inside your job run.
If you want to send an event from outside a run (e.g. just from your backend) you should use client.sendEvent() instead.
sendEvents
This task allows you to send multiple events from inside your job run.
If you want to send multiple events from outside a run (e.g. just from your backend) you should use client.sendEvents() instead.
getEvent
This task allows you to get an event by ID from inside your job run.
If you want to get an event from outside a run (e.g. just from your backend) you should use client.getEvent() instead.
cancelEvent
If you send an event that has a delivery date in the future, you can use this task to cancel it.
createStatus
Coming soon
Was this page helpful?