|
| 1 | +--- |
| 2 | +title: "Using runs.list() efficiently" |
| 3 | +sidebarTitle: "runs.list() best practices" |
| 4 | +description: "When to use runs.list(), the patterns to avoid, and what to use instead." |
| 5 | +--- |
| 6 | + |
| 7 | +`runs.list()` (and `GET /api/v1/runs`) is built for browsing, reporting, and bulk operations. It is not a coordination tool. Each call searches your environment's runs in the requested time window, so its cost depends on how many runs you created in that window much more than on the page size you ask for. |
| 8 | + |
| 9 | +A call with `limit: 4` in a busy environment can still search millions of runs to find those 4. That's fine once in a while. On a hot path, like before every trigger or in a loop every second, it slows your own code down and counts against your [API rate limit](/limits). |
| 10 | + |
| 11 | +## Quick reference |
| 12 | + |
| 13 | +| You want to… | Avoid | Use instead | |
| 14 | +| --- | --- | --- | |
| 15 | +| Avoid piling up runs for the same work | `runs.list()` then `trigger()` | [`debounce`](/triggering#debounce) to merge a burst into one run, a [concurrency limit](/concurrency) so runs queue instead of overlapping, or an [`idempotencyKey`](/idempotency) for one run per item | |
| 16 | +| Collapse a burst of triggers into one run | A fixed `delay` on every trigger | [`debounce`](/triggering#debounce) | |
| 17 | +| Avoid duplicate runs for the same work | A random `idempotencyKey` per trigger | A key derived from the work itself | |
| 18 | +| Wait for a run you triggered | Polling `runs.list()` or `runs.retrieve()` | [`triggerAndWait()`](/triggering#yourtask-triggerandwait) inside a task, or [`runs.subscribeToRun()`](/realtime/backend/subscribe) | |
| 19 | +| Follow a group of runs | Polling `runs.list({ tag })` | [`runs.subscribeToRunsWithTag()`](/realtime/backend/subscribe) | |
| 20 | +| Know how backed up a queue is | Counting `QUEUED` runs with `runs.list()` | [`queues.retrieve()`](/queues#retrieving-a-queue) | |
| 21 | + |
| 22 | +## Anti-patterns |
| 23 | + |
| 24 | +### Checking for active runs before triggering |
| 25 | + |
| 26 | +This pattern tries to make sure only one run handles a piece of work at a time: |
| 27 | + |
| 28 | +```ts Avoid |
| 29 | +import { runs, tasks } from "@trigger.dev/sdk"; |
| 30 | + |
| 31 | +// Called every time something changes for this account |
| 32 | +export async function onAccountChanged(accountId: string) { |
| 33 | + const active = await runs.list({ |
| 34 | + status: ["QUEUED", "EXECUTING"], |
| 35 | + taskIdentifier: ["sync-account"], |
| 36 | + tag: [`account:${accountId}`], |
| 37 | + limit: 1, |
| 38 | + }); |
| 39 | + |
| 40 | + if (active.data.length > 0) return; |
| 41 | + |
| 42 | + await tasks.trigger( |
| 43 | + "sync-account", |
| 44 | + { accountId }, |
| 45 | + { tags: [`account:${accountId}`] } |
| 46 | + ); |
| 47 | +} |
| 48 | +``` |
| 49 | + |
| 50 | +It has three problems: |
| 51 | + |
| 52 | +- **It races.** Two calls can both see "nothing running" and both trigger. |
| 53 | +- **It's expensive.** Every change runs a search, and the search gets slower as you create more runs. |
| 54 | +- **It doesn't collapse bursts.** 100 changes in a second still mean 100 searches. |
| 55 | + |
| 56 | +Let Trigger.dev do the coordination instead. |
| 57 | + |
| 58 | +**To collapse bursts into one run, use `debounce`.** While a debounced run is still waiting for its delay, triggers with the same key push it back instead of creating new runs: |
| 59 | + |
| 60 | +```ts Use debounce |
| 61 | +import { tasks } from "@trigger.dev/sdk"; |
| 62 | + |
| 63 | +export async function onAccountChanged(accountId: string) { |
| 64 | + await tasks.trigger( |
| 65 | + "sync-account", |
| 66 | + { accountId }, |
| 67 | + { |
| 68 | + debounce: { |
| 69 | + key: `account-${accountId}`, |
| 70 | + delay: "10s", |
| 71 | + // The run uses the payload of the last trigger |
| 72 | + mode: "trailing", |
| 73 | + // Never push it back past 1m after the first trigger |
| 74 | + maxDelay: "1m", |
| 75 | + }, |
| 76 | + } |
| 77 | + ); |
| 78 | +} |
| 79 | +``` |
| 80 | + |
| 81 | +<Tip> |
| 82 | + With debounce, one run handles many changes. Have the task read the pending work from your own |
| 83 | + database when it starts, instead of relying on a single trigger's payload. |
| 84 | +</Tip> |
| 85 | + |
| 86 | +**To never run two at once for the same key, use a per-key concurrency limit.** Extra runs wait in the queue instead of running in parallel: |
| 87 | + |
| 88 | +```ts Use a concurrency limit |
| 89 | +import { task } from "@trigger.dev/sdk"; |
| 90 | + |
| 91 | +export const syncAccount = task({ |
| 92 | + id: "sync-account", |
| 93 | + concurrency: { perKey: 1 }, |
| 94 | + run: async ({ accountId }: { accountId: string }) => { |
| 95 | + // ... |
| 96 | + }, |
| 97 | +}); |
| 98 | + |
| 99 | +// When triggering |
| 100 | +await syncAccount.trigger({ accountId }, { concurrencyKey: accountId }); |
| 101 | +``` |
| 102 | + |
| 103 | +The `concurrency` option requires SDK 4.7.0 or later. See [Concurrency](/concurrency) for details. |
| 104 | + |
| 105 | +Debounce only merges triggers into a run that hasn't started yet. Once that run is queued or executing, the next trigger creates a new run. Combine both options so bursts collapse and a new run never overlaps one that's still going. |
| 106 | + |
| 107 | +**For exactly one run per piece of work, use an `idempotencyKey`.** See [Using a random idempotency key](#using-a-random-idempotency-key) below. |
| 108 | + |
| 109 | +### Using a fixed delay to space out triggers |
| 110 | + |
| 111 | +Adding the same `delay` to every trigger doesn't collapse anything. Each trigger still creates its own run. It just starts later: |
| 112 | + |
| 113 | +```ts Avoid |
| 114 | +// 100 changes still create 100 runs, each one 30s after its trigger |
| 115 | +await tasks.trigger("sync-account", { accountId }, { delay: "30s" }); |
| 116 | +``` |
| 117 | + |
| 118 | +Use [`debounce`](#checking-for-active-runs-before-triggering) with the same key instead, so triggers within the delay join one run. |
| 119 | + |
| 120 | +### Using a random idempotency key |
| 121 | + |
| 122 | +An idempotency key only dedupes triggers that send the same key. A fresh random value on every trigger never matches, so every call creates a new run: |
| 123 | + |
| 124 | +```ts Avoid |
| 125 | +await tasks.trigger("sync-account", payload, { |
| 126 | + // Never matches another trigger, so it dedupes nothing |
| 127 | + idempotencyKey: `sync-${crypto.randomUUID()}`, |
| 128 | +}); |
| 129 | +``` |
| 130 | + |
| 131 | +Build the key from the thing that should only happen once: |
| 132 | + |
| 133 | +```ts Your backend |
| 134 | +import { tasks } from "@trigger.dev/sdk"; |
| 135 | + |
| 136 | +// One run per change, even if this code runs again within 30 days |
| 137 | +// (the default key lifetime, set with idempotencyKeyTTL) |
| 138 | +await tasks.trigger("process-change", payload, { |
| 139 | + idempotencyKey: `change-${change.id}`, |
| 140 | +}); |
| 141 | +``` |
| 142 | + |
| 143 | +<Note> |
| 144 | + Inside a task, a raw string key is scoped to the current run. To dedupe across runs, create it |
| 145 | + with `idempotencyKeys.create(key, { scope: "global" })`. See [Idempotency](/idempotency) for |
| 146 | + scopes and TTLs. |
| 147 | +</Note> |
| 148 | + |
| 149 | +### Polling for a run's status |
| 150 | + |
| 151 | +```ts Avoid |
| 152 | +const handle = await tasks.trigger("generate-report", payload); |
| 153 | + |
| 154 | +while (true) { |
| 155 | + const run = await runs.retrieve(handle.id); |
| 156 | + if (run.isCompleted) break; |
| 157 | + await new Promise((resolve) => setTimeout(resolve, 1000)); |
| 158 | +} |
| 159 | +``` |
| 160 | + |
| 161 | +Inside a task, use [`triggerAndWait()`](/triggering#yourtask-triggerandwait). You don't pay for compute during waits longer than 5 seconds. |
| 162 | + |
| 163 | +From your backend, subscribe to the run. The loop ends when the run finishes: |
| 164 | + |
| 165 | +```ts Use realtime |
| 166 | +import { runs, tasks } from "@trigger.dev/sdk"; |
| 167 | + |
| 168 | +const handle = await tasks.trigger("generate-report", payload); |
| 169 | + |
| 170 | +for await (const run of runs.subscribeToRun(handle.id)) { |
| 171 | + console.log(run.status); |
| 172 | +} |
| 173 | +``` |
| 174 | + |
| 175 | +### Polling runs by tag to follow progress |
| 176 | + |
| 177 | +Calling `runs.list({ tag })` on a timer to see what a user's or a job's runs are doing repeats the same search every time. Subscribe once instead: |
| 178 | + |
| 179 | +```ts Use realtime |
| 180 | +import { runs } from "@trigger.dev/sdk"; |
| 181 | + |
| 182 | +const tag = `user:${userId}`; |
| 183 | + |
| 184 | +for await (const run of runs.subscribeToRunsWithTag(tag)) { |
| 185 | + console.log(run.id, run.status); |
| 186 | +} |
| 187 | +``` |
| 188 | + |
| 189 | +This iterator never completes on its own, so break out of the loop when you're done. In a frontend, use the [React hooks](/realtime/react-hooks/overview). |
| 190 | + |
| 191 | +<Note> |
| 192 | + Tag subscriptions only include runs created in the last 24 hours. You can narrow that with the |
| 193 | + `createdAt` option, but not extend it. To follow a specific older run, use |
| 194 | + `runs.subscribeToRun(runId)`. |
| 195 | +</Note> |
| 196 | + |
| 197 | +### Counting runs to measure a backlog |
| 198 | + |
| 199 | +Listing `QUEUED` runs to count them gets slower as the backlog grows, which is exactly when you need the number. It can also miss runs: queued runs created before the [time window](#when-you-do-need-runs-list) aren't returned. The queue already tracks the count: |
| 200 | + |
| 201 | +```ts Use queues.retrieve() |
| 202 | +import { queues } from "@trigger.dev/sdk"; |
| 203 | + |
| 204 | +// A task's default queue is named after the task ID |
| 205 | +const queue = await queues.retrieve({ |
| 206 | + type: "task", |
| 207 | + name: "sync-account", |
| 208 | +}); |
| 209 | + |
| 210 | +console.log(queue.queued, queue.running); |
| 211 | +``` |
| 212 | + |
| 213 | +For a queue shared between tasks, use `{ type: "custom", name: "your-queue-name" }`. |
| 214 | + |
| 215 | +## When you do need runs.list() |
| 216 | + |
| 217 | +`runs.list()` is the right tool for dashboards, reports, audits, and finding runs to act on in bulk. To keep it fast: |
| 218 | + |
| 219 | +- **Pass a time window.** Use the narrowest `period` (or `from`/`to`) that covers what you need, like `period: "1h"`. |
| 220 | +- **Filter by `taskIdentifier`** as well as status or tag. |
| 221 | +- **Stop paginating once you have what you need.** Don't page through every result by default. |
| 222 | +- **Keep it off hot paths.** Don't call it per event, per trigger, or in a tight loop inside a task. If several places need the same answer, cache it. |
| 223 | + |
| 224 | +<Warning> |
| 225 | + If you don't pass `period`, `from`, or `to`, only runs created in the last 7 days are searched. |
| 226 | + The window applies to every status, so runs created before it aren't returned even if they're |
| 227 | + still queued or executing. Passing only `to` removes the lower bound, so the search covers every |
| 228 | + run up to that date. |
| 229 | +</Warning> |
| 230 | + |
| 231 | +<Note> |
| 232 | + If a query would be too expensive to complete, the API returns a `422` asking you to narrow the |
| 233 | + time window. The SDK doesn't retry it. |
| 234 | +</Note> |
0 commit comments