Trigger.dev v3 provides a powerful platform for durable background tasks. These exercises cover the Task abstraction, delay mechanisms, batch triggering, idempotency, and retry configuration for building reliable production workflows.
0 / 5 completed
1 / 5
At standup, a colleague asks what a Task is in Trigger.dev v3. What is the correct answer?
In Trigger.dev v3, a Task is defined using the task() helper, specifying an id, optional retry policy, and a run function. Tasks execute on Trigger.dev's cloud workers (or your own infrastructure) and are fully durable — retried automatically on failure, with structured logs and traces visible in the Trigger.dev dashboard. They are the replacement for the v2 Job concept.
2 / 5
During a PR review, a teammate asks what delays in Trigger.dev tasks enable. Which answer is correct?
Trigger.dev's wait.for() and wait.until() functions provide durable delays inside tasks. The task suspends completely — no compute consumed — and Trigger.dev automatically resumes it after the specified duration. This is suitable for any duration from seconds to weeks. Unlike setTimeout, the delay survives server restarts and does not require a running process.
3 / 5
In a design review, the team discusses batch triggers in Trigger.dev. A junior engineer asks what they enable. What is correct?
Batch triggers in Trigger.dev let you kick off many runs of the same task simultaneously with a single call. You pass an array of payloads to tasks.batchTrigger('my-task', items) and Trigger.dev enqueues each item as a separate run. The response includes a batch ID and individual run IDs so you can monitor progress. This is efficient for fan-out patterns like processing a large list of records.
4 / 5
An incident report shows duplicate task executions during a redeploy. A senior engineer asks what idempotency keys do in Trigger.dev. What is correct?
Idempotency keys in Trigger.dev prevent duplicate task runs. When you call tasks.trigger('my-task', payload, { idempotencyKey: 'order-123' }), Trigger.dev checks if a run with that key was already created. If so, it returns the existing run ID rather than creating a new execution. This is essential for at-least-once delivery scenarios — such as webhook retries or form submission double-clicks — where the same trigger may fire multiple times.
5 / 5
During a code review, a senior engineer asks how retry policies are configured in Trigger.dev v3 tasks. What is accurate?
In Trigger.dev v3, retry behaviour is configured per task in the task() definition. The retry object accepts maxAttempts (max number of retries), minTimeoutInMs (initial delay), maxTimeoutInMs (cap on delay), and factor (exponential backoff multiplier). For example, retry: { maxAttempts: 5, minTimeoutInMs: 1000, factor: 2 } gives exponential backoff with delays 1s, 2s, 4s, 8s. Errors thrown from run() automatically trigger retries.