Build fluency in Trigger.dev's job orchestration vocabulary — durable waits, event chaining, retry policies, and fan-out patterns.
0 / 5 completed
1 / 5
During a PR review, a teammate asks why you wrapped a slow image-processing step in a Trigger.dev job instead of running it inline in the API route. The answer is:
Trigger.dev jobs execute outside the HTTP request, avoiding serverless function timeouts (e.g. Vercel's 10s limit). They support retries, delays, and long-running tasks natively.
2 / 5
In a code review, a job uses io.wait("pause", 60). A junior engineer asks what this does. The correct answer is:
io.wait() durably suspends the job — the worker is freed and the job resumes after the specified delay. This enables multi-day workflows without holding a server connection open.
3 / 5
Your team wants a job to trigger another job and wait for its result. In a design review, you recommend io.triggerAndWait(). What does it do?
io.triggerAndWait() fires a child Trigger.dev job and durably suspends the parent until the child finishes, returning the child's result — enabling fan-out/fan-in patterns.
4 / 5
In a standup, a job that calls a flaky external API keeps failing permanently. You note the job definition lacks a retry policy. In Trigger.dev, retry policies are configured:
Trigger.dev retry policies are set on io.runTask() or the job itself via a retry config object specifying maxAttempts, backoff factor, and timeout bounds.
5 / 5
During a platform review, a colleague asks what io.sendEvent() does inside a running job. The correct answer is:
io.sendEvent() publishes a named event to Trigger.dev's event bus. Other jobs registered with trigger: eventTrigger({ name }) will fire in response, enabling event-driven pipelines.