Define a business operation before configuring retries
For an illustrative CSV-import service, one import request should create one set of accepted records and one completion notification. Give that request a stable internal identifier. Decide whether a later user request is a retry of the same import or a new import with different input.
Trigger.dev supports project-level and task-level retry settings, with task settings overriding the defaults. Separate a temporary failure from invalid input that another attempt will not fix. A retry count is useful only when the team understands what each attempt may repeat.
Keep trigger deduplication separate from external writes
Trigger.dev's idempotency documentation explicitly distinguishes deduplicating a trigger from making the task's code idempotent. Retried runs execute their run function again. A child task triggered once can still retry its own external call after that call succeeded but its response was lost.
For the import example, protect stored records with the application's operation identity and suitable database constraints. If an external provider supports an idempotency key for the notification request, pass the stable key to that provider as well. A successful task-trigger response cannot establish that every later side effect will occur exactly once.
| Boundary | Identity to establish | Failure to rehearse |
|---|---|---|
| Import submission | One import operation | The same submission arrives twice |
| Child task trigger | The intended child run and scope | Parent retries after triggering the child |
| Record persistence | Import and row identity | Two attempts try the same insert |
| External notification | Provider-supported operation key | Provider accepts but the response is lost |
Choose the key scope that matches the duplicate
Trigger.dev documents run, attempt, and global key scopes. Run scope separates different parent runs; attempt scope separates attempts; global scope can deduplicate across parents but remains scoped to the task and environment. Match the scope to the duplicate you want to prevent.
In the CSV service, reusing a short label such as send-email may be appropriate only within a deliberately scoped context. If the goal is to deduplicate the same import across separate submissions, include that business operation in the key design. Avoid making an entire customer's future imports collide with their first one.
Treat key lifetime and failed runs as explicit behavior
Idempotency keys have a configurable lifetime, after which the same key can create another run. Trigger.dev also documents clearing the key when a run fails, while successful and canceled runs keep theirs. A key is therefore not a permanent application record of a completed business operation.
Decide how long a duplicate submission can realistically arrive and how a deliberately requested re-import should work. Keep the durable import result in your own application record. If a failed run is submitted again, that record should let the new attempt recognize already accepted rows instead of assuming every previous action was undone.
Observe the attempt and the final customer result
Trigger.dev exposes task lifecycle hooks, with distinct attempt and final-failure behavior. Its task documentation notes that some terminal statuses do not invoke the ordinary failure hook. Review the statuses and monitoring path relevant to your deployment rather than assuming one callback captures every operational problem.
For the import service, connect the customer-facing import identifier to the run and its result. Record accepted, rejected, and pending rows separately. A support person should be able to explain whether an import is still progressing, needs corrected input, or failed after partial progress.
Test a failure after progress has already been made
In a non-production workflow, make a small sample import write a record and then fail before reporting completion. Allow the configured recovery path and inspect the final records and notifications. Repeat with a duplicate top-level submission and with a failed child operation.
The useful acceptance criterion is one understandable business result, with safe recovery from partial progress. Trigger.dev can manage task execution and retries, while your application still owns the meaning of a completed import and the constraints around its external effects.
Sources and editorial method
Official sources linked in this guide were checked on October 27, 2026. Product features, interfaces, and plan limits can change. The examples are proposed workflows, not reports of a hands-on benchmark or customer results. Confirm the documentation for your product version before implementing a workflow.