docs: idempotency keys deduplicate triggers, not side effects inside run() - #4952
Conversation
…run() The idempotency page listed avoiding double charges as a use case, but its examples only ever deduplicate a child trigger. A payment call made directly inside a retryable run() gets no protection from the Trigger.dev key. The page now states the boundary up front and adds a section showing the provider's own idempotency key (Stripe) alongside the Trigger.dev key.
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📜 Recent review details🧰 Additional context used📓 Path-based instructions (1)MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format Use Mintlify components for structured content: , , , , ,
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Description check | The description explains the motivation, scope, and changes clearly, but it omits required template sections for the checklist, testing steps, changelog, and screenshots. It also references issues wit… | Add the required checklist, testing details, changelog, and screenshots sections. Include the relevant issue using the template's Closes # format, or explain why that format does not apply. |
✅ Passed checks (4 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly and concisely describes the main documentation change: trigger idempotency keys do not make side effects inside run() idempotent. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
Full details: Description check
Explanation
The description explains the motivation, scope, and changes clearly, but it omits required template sections for the checklist, testing steps, changelog, and screenshots. It also references issues without using the required Closes #<issue> format.
- Fix all pre-merge checks with AI
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Commit to this branch
- Create a new PR
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
…iggerdotdev#4953) ## Summary Follow-up to [triggerdotdev#4952](triggerdotdev#4952). The new "Side effects inside `run()`" section told readers to derive the provider's idempotency key from a payload ID, but the more general answer is the run ID: `ctx.run.id` is stable across every attempt of a run, is always available, and is the same value the default `run` scope already mixes into a Trigger.dev idempotency key. The Stripe refund example now keys the provider call on `ctx.run.id`, and a short paragraph explains when a business ID from the payload is the better choice (when the same task can be triggered more than once for the same order and you want deduplication across separate runs). Docs only.
2 participants
Summary
Idempotency keys deduplicate task triggers (
trigger(),triggerAndWait(),batchTrigger()). They do not make the code inside a task'srun()idempotent: when a run retries,run()executes again from the top, and any API call inside it happens again unless that call is itself idempotent.The idempotency page listed "avoiding double-charging customers" as a use case, but every example on the page only ever deduplicated a child trigger, so a reader could reasonably assume a payment call made directly inside a retryable
run()was protected. It is not, and no Trigger.dev-side mechanism can protect it: only the payment provider can deduplicate its own API call, so the provider's idempotency key has to be passed too.This is a docs-only change. No SDK changes.
What changed
run()" section explains why moving the call into a child task does not close the gap either, and shows a Stripe refund passing Stripe'sidempotencyKeyalongside a Trigger.dev key for the follow-up email trigger.Addresses the documentation side of #4627. Supersedes #4650, which was auto-closed by the vouch gate.