Docs: Fixes incorrect retrieving runs from batchTrigger #2427
Conversation
|
WalkthroughThis PR updates documentation and snippets related to v4 migration and tags. It changes the pattern for accessing batch runs: instead of batchHandle.runs.list(), you now call batch.retrieve(batchHandle.batchId) and read batch.runs. Snippets are updated to reflect this flow. The tags docs increase the per-run tag limit from 5 to 10 and clarify error behavior when exceeding 10. The v4 upgrade guide (docs/upgrade-to-v4.mdx) is removed entirely. The snippets doc notes a retrieve(batchId) method and a runs property on Batch, and deprecates the batchHandle.runs.list() access pattern. 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: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/migrating-from-v3.mdx (1)
293-305: Rename localbatchto avoid shadowing thebatchmoduleSame issue as in the snippet file: using
batchas a variable name conflicts with the importedbatchmodule/namespace.Apply this diff:
-// Now you need to retrieve the batch to get the runs -const batch = await batch.retrieve(batchHandle.batchId); -console.log(batch.runs); +// Now you need to retrieve the batch to get the runs +const retrievedBatch = await batch.retrieve(batchHandle.batchId); +console.log(retrievedBatch.runs);Consider also showing the relevant import in the example or nearby docs to make origin explicit:
import { batch } from "@trigger.dev/sdk";
📜 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 (4)
docs/migrating-from-v3.mdx(2 hunks)docs/snippets/migrate-v4-using-ai.mdx(1 hunks)docs/tags.mdx(1 hunks)docs/upgrade-to-v4.mdx(0 hunks)
💤 Files with no reviewable changes (1)
- docs/upgrade-to-v4.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/tags.mdx (1)
78-78: Limit update and behavior note look goodThe 10-tag limit and the "log-and-ignore" behavior are clearly stated and consistent with the PR intent.
| const batch = await batch.retrieve(batchHandle.batchId); // Use batch.retrieve() | ||
| console.log(batch.runs); | ||
|
|
There was a problem hiding this comment.
Variable name collision: batch shadows the imported module
const batch = await batch.retrieve(...) shadows the module/namespace and will either be invalid TS or highly confusing. Rename the local variable.
Apply this diff:
-const batch = await batch.retrieve(batchHandle.batchId); // Use batch.retrieve()
-console.log(batch.runs);
+const retrievedBatch = await batch.retrieve(batchHandle.batchId); // Use batch.retrieve()
+console.log(retrievedBatch.runs);Additionally, ensure the snippet (or surrounding text) shows where batch comes from, e.g.:
import { batch } from "@trigger.dev/sdk";🤖 Prompt for AI Agents
In docs/snippets/migrate-v4-using-ai.mdx around lines 203-205, the local
declaration "const batch = await batch.retrieve(...)" shadows the imported
"batch" module; rename the local variable (e.g., batchRecord or batchInstance)
and update subsequent references (console.log) to use the new name, and add or
ensure the snippet shows the module import (import { batch } from
"@trigger.dev/sdk";) earlier in the snippet so it's clear where the module comes
from.
| @@ -75,7 +75,7 @@ export const myTask = task({ | |||
| }); | |||
| ``` | |||
|
|
|||
| Reminder: you can only have up to 5 tags per run. If you call `tags.add()` and the total number of tags will be more than 5 we log an error and ignore the new tags. That includes tags from triggering and from inside the run function. | |||
| Reminder: you can only have up to 10 tags per run. If you call `tags.add()` and the total number of tags will be more than 10 we log an error and ignore the new tags. That includes tags from triggering and from inside the run function. | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify there are no remaining references to a 5-tag limit elsewhere
To avoid conflicting guidance, scan the repo for stale mentions of a 5-tag maximum.
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for common phrasings of the old 5-tag limit across docs
rg -n -C2 -S -g '!**/node_modules/**' -g '!**/dist/**' -e \
$'up to 5 tags|maximum of 5 tags|max(imum)? 5 tags|5 tags per run|no more than 5 tags|limit of 5 tags|only 5 tags' || trueLength of output: 1342
Update stale 5-tag references in the OpenAPI spec
We still have lingering “5 tags” limits in the v3 OpenAPI YAML. Please update them to reflect the new 10-tag maximum.
• docs/v3-openapi.yaml:1610
• docs/v3-openapi.yaml:1831
• docs/v3-openapi.yaml:2008
Suggested diffs:
--- a/docs/v3-openapi.yaml
+++ b/docs/v3-openapi.yaml
@@ -1608,7 +1608,7 @@
- You can set up to 5 tags per run, they must be less than 64 characters each.
+ You can set up to 10 tags per run, they must be less than 64 characters each.
@@ -1831,7 +1831,7 @@
- description: A tag must be between 1 and 64 characters, a run can have up to 5 tags attached to it.
+ description: A tag must be between 1 and 64 characters, a run can have up to 10 tags attached to it.
@@ -2008,7 +2008,7 @@
- description: A tag must be between 1 and 64 characters, a run can have up to 5 tags attached to it.
+ description: A tag must be between 1 and 64 characters, a run can have up to 10 tags attached to it.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Reminder: you can only have up to 10 tags per run. If you call `tags.add()` and the total number of tags will be more than 10 we log an error and ignore the new tags. That includes tags from triggering and from inside the run function. | |
| ++ b/docs/v3-openapi.yaml | |
| @@ -1608,7 +1608,7 @@ | |
| You can set up to 10 tags per run, they must be less than 64 characters each. | |
| @@ -1831,7 +1831,7 @@ | |
| description: A tag must be between 1 and 64 characters, a run can have up to 10 tags attached to it. | |
| @@ -2008,7 +2008,7 @@ | |
| description: A tag must be between 1 and 64 characters, a run can have up to 10 tags attached to it. |
Main change
migrating-from-v3docs page batchTrigger section with the correct way to retrieve runs.Additional changes