Updated queue/concurrency docs for v4 #2418
Conversation
|
WalkthroughDocumentation for queue/concurrency was rewritten to center on queues rather than per-task concurrency. Default concurrency is now described as bounded by environment limits; “burst limits” terminology is used. The “Setting the concurrency when you trigger a run” section becomes “Setting the queue when you trigger a run,” with examples showing queue overrides (e.g., paid vs free). Per-tenant behavior clarifies that concurrencyKey duplicates a queue per key value. Subtasks are stated not to inherit the parent’s queue. Content about same-queue waits and deadlocks was removed. Behavior for waiting on subtasks in different queues remains, with wording aligned to queue terminology. Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/queue-concurrency.mdx (2)
74-96: Define the “free-users” queue and normalize comment styleLater examples reference a “free-users” queue with concurrencyLimit: 1, but it isn’t defined. Adding it here prevents confusion. Also normalize comment casing/spacing and TODO.
```ts /trigger/override-concurrency.ts const paidQueue = queue({ name: "paid-users", concurrencyLimit: 10, }); + +const freeQueue = queue({ + name: "free-users", + concurrencyLimit: 1, +}); export const generatePullRequest = task({ id: "generate-pull-request", queue: { - //normally when triggering this task it will be limited to 1 run at a time + // Normally, triggering this task uses its default queue with a concurrency limit of 1 concurrencyLimit: 1, }, run: async (payload) => { - //todo generate a PR using OpenAI + // TODO: generate a PR using OpenAI }, });--- `126-158`: **Clarify concurrencyKey semantics and align examples with defined queues** Two issues: - “Creates a copy of the queue” is imprecise; it partitions the queue per key with independent counters. - Comments claim “free-users” has concurrencyLimit: 1 but the queue wasn’t defined until the earlier fix. Make that explicit in comments to avoid implying implicit defaults. ```diff -You can do this by using `concurrencyKey`. It creates a copy of the queue for each unique value of the key. +You can do this by using `concurrencyKey`. It partitions the queue by key so each unique key value gets its own independent concurrency counters. - //the "free-users" queue has a concurrency limit of 1 + // The "free-users" queue (defined above) has a concurrency limit of 1 @@ - //this creates a free-users queue for each user + // This partitions the "free-users" queue per userId (independent concurrency per user) @@ - //the "paid-users" queue has a concurrency limit of 10 + // The "paid-users" queue (defined above) has a concurrency limit of 10 @@ - //this creates a paid-users queue for each user + // This partitions the "paid-users" queue per userId (independent concurrency per user)
🧹 Nitpick comments (5)
docs/queue-concurrency.mdx (5)
6-8: Good intro; minor wording to tighten “limited by” phrasingThe new queue-first framing reads well. Consider a small clarity tweak to avoid the “limited by limit” phrasing and align with later sections.
-By default, each task gets its own queue and the concurrency is only limited by your environment concurrency limit. If you need more control (for example, to limit concurrency or share limits across multiple tasks), you can define a custom queue as described later. +By default, each task gets its own queue and effective concurrency is bounded by your environment’s concurrency limits. If you need more control (for example, to limit concurrency or share limits across multiple tasks), you can define a custom queue as described later.
16-16: Avoid tautology in “unbounded … limited only by …”Reads as contradictory. Suggest simplifying to match the queue-first model and the “bounded by environment” wording.
-By default, all tasks have an unbounded concurrency limit, limited only by the overall concurrency limits of your environment. +By default, tasks do not set an explicit concurrencyLimit; effective concurrency is bounded by your environment’s limits.
19-24: Minor copyedit: punctuation and consistency around “burst/burstable”Optional polish: add a comma after “customer” and keep “burst” terminology consistent.
- but any single queue can have at most 10 concurrent runs. If you're a paying customer you can - request higher burst limits by [contacting us](https://www.trigger.dev/contact). + but any single queue can have at most 10 concurrent runs. If you're a paying customer, you can + request higher burst limits by [contacting us](https://www.trigger.dev/contact).
162-162: Punctuation and explicitness about overridesAdd a period and make it explicit that subtasks can set their own queue.
-When you trigger a task that has subtasks, the subtasks will not inherit the queue from the parent task. Unless otherwise specified, subtasks will run on their own queue +When you trigger a task that has subtasks, the subtasks will not inherit the queue from the parent task. Unless otherwise specified, subtasks will run on their own queue.
213-217: Move/adjust checkpoint comment to the await locationThe checkpoint occurs at the await. Place the comment at that line for accuracy.
- //trigger a subtask and wait for it to complete - await subtask.triggerAndWait(payload); - // The parent task checkpoints here and releases its concurrency slot - // allowing other tasks to execute while waiting + // Trigger a subtask and wait for it to complete. + // The parent task checkpoints at this await and releases its concurrency slot, + // allowing other tasks to execute while waiting. + await subtask.triggerAndWait(payload);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
docs/queue-concurrency.mdx(7 hunks)
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-08-18T10:07:17.345Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.345Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Define tasks using task({ id, run, ... }) with a unique id per project
Applied to files:
docs/queue-concurrency.mdx
📚 Learning: 2025-08-18T10:07:17.345Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.345Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : For idempotent child-task invocations, create and pass idempotencyKey (and optional TTL) when calling trigger()/batchTrigger() from tasks
Applied to files:
docs/queue-concurrency.mdx
📚 Learning: 2025-08-18T10:07:17.345Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.345Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Export every task (including subtasks) defined with task(), schedules.task(), or schemaTask()
Applied to files:
docs/queue-concurrency.mdx
📚 Learning: 2025-08-18T10:07:17.345Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.345Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task multiple times in a loop from inside another task, use batchTrigger()/batchTriggerAndWait() instead of per-item trigger() calls
Applied to files:
docs/queue-concurrency.mdx
📚 Learning: 2025-08-18T10:07:17.345Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.345Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Use schedules.task(...) for scheduled (cron) tasks; do not implement schedules as plain task() with external cron logic
Applied to files:
docs/queue-concurrency.mdx
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
docs/queue-concurrency.mdx (1)
98-121: Queue override example: apply style nits and confirm trigger options API
- In docs/queue-concurrency.mdx (around lines 98–121), update the inline comments for consistency and clarity:
if (data.branch === "main") { - //trigger the task, with the paid users queue + // Trigger the task using the paid-users queue const handle = await generatePullRequest.trigger(data, { queue: "paid-users", }); return Response.json(handle); } else { - //triggered with the default queue (concurrency of 1) + // Triggered with the task’s default queue (concurrencyLimit: 1) const handle = await generatePullRequest.trigger(data); return Response.json(handle); }
- Confirmed that the
triggermethod accepts an options object of shape{ queue: string; concurrencyKey?: string }.
No description provided.