docs(wait): separate compute billing from concurrency release - #4405
Conversation
The wait pages described the 5 second compute-billing threshold as if it were also the suspension threshold. It isn't: `wait.for` and `wait.until` only checkpoint 60 seconds into the wait, so a shorter wait stays EXECUTING and holds its concurrency slot for the whole wait even though the compute is free. Splits the two facts in the shared wait snippet and corrects the same conflation on the concurrency, spend and how-it-works pages.
|
WalkthroughUpdated documentation to define checkpoint behavior for waits under 60 seconds, change a checkpoint-resume example to a five-minute wait, clarify compute charging for waits longer than five seconds, and explain when concurrency slots are released during 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f206d4b3-f285-4024-8af0-d03e09d639cc
📒 Files selected for processing (4)
docs/how-it-works.mdxdocs/how-to-reduce-your-spend.mdxdocs/queue-concurrency.mdxdocs/snippets/paused-execution-free.mdx
📜 Review details
⏰ Context from checks skipped due to timeout. (5)
- GitHub Check: code-quality / code-quality
- GitHub Check: check-vouch
- GitHub Check: check-broken-links
- GitHub Check: Analyze (actions)
- GitHub Check: Analyze (javascript-typescript)
🧰 Additional context used
📓 Path-based instructions (1)
docs/**/*.mdx
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/*.mdx: MDX documentation pages must include frontmatter with title (required), description (required), and sidebarTitle (optional) in YAML format
Use Mintlify components for structured content: , , , , , , /, /
Always import from@trigger.dev/sdkin code examples (never from@trigger.dev/sdk/v3)
Code examples must be complete and runnable where possible
Use language tags in code fences:typescript,bash,jsonDocumentation in
docs/uses MDX conventions defined by the documentation guidance.
Files:
docs/snippets/paused-execution-free.mdxdocs/queue-concurrency.mdxdocs/how-it-works.mdxdocs/how-to-reduce-your-spend.mdx
🧠 Learnings (2)
📚 Learning: 2026-03-10T12:44:14.176Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:14.176Z
Learning: In the trigger.dev repo, docs PRs are often companions to implementation PRs. When reviewing docs PRs (MDX files under docs/), check the PR description for any companion/related PR references and verify that the documented features exist in those companion PRs before flagging missing implementations. This ensures docs stay in sync with code changes across related PRs.
Applied to files:
docs/snippets/paused-execution-free.mdxdocs/queue-concurrency.mdxdocs/how-it-works.mdxdocs/how-to-reduce-your-spend.mdx
📚 Learning: 2026-04-30T20:30:29.458Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3226
File: docs/ai-chat/quick-start.mdx:13-13
Timestamp: 2026-04-30T20:30:29.458Z
Learning: In this repo’s documentation MDX files (`docs/**/*.mdx`), use `ts` and `tsx` (not `typescript`) as the code-fence language tags for TypeScript/TSX snippets. Do not flag `ts`/`tsx` code-fence language tags as incorrect in any docs MDX file, since this is the site-wide Mintlify-compatible convention.
Applied to files:
docs/snippets/paused-execution-free.mdxdocs/queue-concurrency.mdxdocs/how-it-works.mdxdocs/how-to-reduce-your-spend.mdx
🔇 Additional comments (4)
docs/how-it-works.mdx (1)
151-151: LGTM!Also applies to: 181-183
docs/how-to-reduce-your-spend.mdx (1)
173-174: LGTM!Also applies to: 176-191
docs/queue-concurrency.mdx (1)
202-205: LGTM!docs/snippets/paused-execution-free.mdx (1)
4-6: LGTM!
2 participants
The wait docs describe the 5 second compute-billing threshold as if it were also the suspension threshold. It isn't, and the gap is confusing when you're sizing a poll interval:
wait.forandwait.untilthat happens 60 seconds into the wait — a shorter wait staysEXECUTINGand holds its concurrency slot for the whole wait, even though the compute is free.So
await wait.for({ seconds: 30 })in a polling loop never releases its slot, which looks like a bug if the docs told you waits over 5 seconds checkpoint.Changes
docs/snippets/paused-execution-free.mdx— rendered on/wait,/wait-forand/wait-until. Drops "we checkpoint and" from the billing sentence so it's purely about compute, then adds one paragraph for the concurrency half.docs/queue-concurrency.mdx— the "Waits and concurrency" section states flatly that waiting runs don't consume slots. Adds a short subsection for the time-based exception.docs/how-to-reduce-your-spend.mdx— "Waits longer than 5 seconds automatically checkpoint your task, meaning you don't pay for compute" → the compute claim only. Code comments follow, plus a pointer that waiting doesn't always free concurrency.docs/how-it-works.mdx— the Checkpoint-Resume walkthrough usedwait.for({ seconds: 30 })as the example of a wait that suspends. Bumped to 5 minutes and noted the sub-60s exception.No behaviour change — docs only.