Conversation
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
WalkthroughAdds a new documentation guide "Nango OAuth with Trigger.dev" at docs/guides/frameworks/nango.mdx and updates docs/docs.json to include the new page under Guides → AI Agents → Guides & examples (inserted between Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/guides/frameworks/nango.mdx (1)
162-162: Clarify the integration slug placeholder.The placeholder
<your-integration-slug>requires users to find their integration slug in the Nango dashboard. While the comment mentions this, it would be helpful to reference the earlier step where "GitHub (User OAuth)" was set up, or provide a concrete example.💡 Suggested improvement
Consider updating the comment to be more explicit:
- // Fetch a fresh access token from Nango. It handles refresh automatically. - // Use the exact integration slug from your Nango dashboard, e.g. "github-getting-started" + // Fetch a fresh access token from Nango. It handles refresh automatically. + // Replace with your integration slug from Step 1 (e.g., "github", "github-getting-started"). + // Find this in your Nango dashboard under Integrations. const connection = await nango.getConnection("<your-integration-slug>", connectionId);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/guides/frameworks/nango.mdx` at line 162, Clarify the placeholder used in the nango.getConnection call by replacing or augmenting "<your-integration-slug>" with a clearer reference and example; update the comment around the nango.getConnection(...) usage to tell users to use the integration slug shown in the Nango dashboard (for this guide, reference the earlier "GitHub (User OAuth)" setup step) and include a concrete example slug such as "github" or "github-user-oauth" so readers know what value to pass to nango.getConnection.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/guides/frameworks/nango.mdx`:
- Line 162: Clarify the placeholder used in the nango.getConnection call by
replacing or augmenting "<your-integration-slug>" with a clearer reference and
example; update the comment around the nango.getConnection(...) usage to tell
users to use the integration slug shown in the Nango dashboard (for this guide,
reference the earlier "GitHub (User OAuth)" setup step) and include a concrete
example slug such as "github" or "github-user-oauth" so readers know what value
to pass to nango.getConnection.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 10ee2e81-c4c3-46a4-bd8c-5a70ab4d346b
📒 Files selected for processing (2)
docs/docs.jsondocs/guides/frameworks/nango.mdx
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
docs/docs.json
docs/**/docs.json
📄 CodeRabbit inference engine (docs/CLAUDE.md)
docs/**/docs.json: Main documentation config must be defined indocs.jsonwhich includes navigation structure, theme, and metadata
Navigation structure indocs.jsonshould be organized usingnavigation.dropdownswith groups and pages
Files:
docs/docs.json
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,json
Files:
docs/guides/frameworks/nango.mdx
🧠 Learnings (7)
📓 Common learnings
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:19.869Z
Learning: In the triggerdotdev/trigger.dev repository, docs PRs are often written as companions to implementation PRs (e.g., PR `#3200` documents features being added in PR `#3196`). When reviewing docs PRs, the documented features may exist in a companion/companion PR branch rather than main. Always check companion PRs referenced in the PR description before flagging missing implementations.
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: New documentation pages must be added to the navigation structure in `docs.json` under the correct group after creating the MDX file
Applied to files:
docs/docs.json
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: Applies to docs/**/docs.json : Navigation structure in `docs.json` should be organized using `navigation.dropdowns` with groups and pages
Applied to files:
docs/docs.json
📚 Learning: 2026-03-02T12:43:02.539Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: Applies to docs/**/docs.json : Main documentation config must be defined in `docs.json` which includes navigation structure, theme, and metadata
Applied to files:
docs/docs.json
📚 Learning: 2026-03-02T12:43:34.140Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/cli-v3/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:34.140Z
Learning: Keep SDK documentation in `rules/` and `.claude/skills/trigger-dev-tasks/` synchronized when features are added or changed
Applied to files:
docs/guides/frameworks/nango.mdx
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `TriggerAuthContext` provider to supply Public Access Token to Trigger.dev React hooks
Applied to files:
docs/guides/frameworks/nango.mdx
📚 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/guides/frameworks/nango.mdx
🪛 LanguageTool
docs/guides/frameworks/nango.mdx
[uncategorized] ~283-~283: The official name of this software platform is spelled with a capital “H”.
Context: ...rks for any Nango-supported API. Change "github" to "hubspot", "slack", "notion"...
(GITHUB)
🔇 Additional comments (9)
docs/docs.json (1)
371-371: Navigation entry added correctly.The new guide is properly placed alongside other framework integration guides (Drizzle, Prisma, Sequin) in the "Guides" section. The alphabetical positioning between Prisma and Sequin makes sense for discoverability.
docs/guides/frameworks/nango.mdx (8)
1-6: Frontmatter is complete and well-structured.All required fields (title, description) and optional fields (sidebarTitle, icon) are present and follow the correct YAML format. The icon choice ("key") is appropriate for an OAuth guide.
8-23: Clear introduction and appropriate prerequisites.The guide sets clear expectations about what will be built and lists the necessary prerequisites with helpful links. The Nango overview effectively explains the value proposition.
27-52: Excellent sequence diagram.The Mermaid diagram clearly illustrates the complete OAuth flow, including the session token exchange, frontend OAuth connection, task triggering, and API calls. This provides valuable context before diving into the implementation.
54-133: Step 1 is comprehensive and follows best practices.The frontend setup is broken down clearly into two parts: backend session token generation and frontend OAuth flow. The code examples are complete, use proper Next.js App Router patterns, and include a helpful note about session token expiration. The Mintlify components are used correctly.
222-241: API route implementation is clean and type-safe.The route handler includes proper input validation, uses type-safe task triggering with
typeof analyzePRs, and returns the task handle. The code is complete and follows Next.js App Router conventions.
243-253: Environment variable setup is clear and complete.The guide correctly notes that Trigger.dev dev mode reads from
.env(not.env.local), which is an important detail for Next.js users. All required API keys are listed with clear sourcing instructions, and the reminder to add them to the Trigger.dev project is helpful.
255-284: Testing steps and next steps are well-structured.The testing section provides clear, sequential instructions using Mintlify components appropriately. The next steps offer valuable suggestions for extending functionality, including connection reuse, automatic retries, provider switching, and streaming analysis. The
<Check>component effectively summarizes the achievement.
199-199: No action needed. The model identifier"claude-opus-4-6"is the correct, current model identifier for the latest Claude Opus model available through the Anthropic API. Claude Opus 4.6 was released on February 5, 2026 and follows Anthropic's naming convention.> Likely an incorrect or invalid review comment.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
docs/guides/frameworks/nango.mdx (2)
286-286: Clarify “provider name” vs “integration slug” in Next Steps.This line says to swap
"github"to other providers, but the guide’s working pattern uses an integration slug (e.g.,<your-integration-slug>). Tightening this wording would avoid misconfiguration.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/guides/frameworks/nango.mdx` at line 286, The sentence suggesting to change "github" to other providers is ambiguous about whether it expects a provider name or an integration slug; update the guidance to explicitly state that you should replace the placeholder with your Nango integration slug (e.g., "<your-integration-slug>") and give provider-name examples ("github", "hubspot", "slack", "notion") to show the difference so readers use their configured integration slug rather than an arbitrary provider string.
113-119: Handle failed API responses before consuming JSON.The frontend example assumes both backend calls succeed. If either fails,
token/payload handling can break and make the guide feel non-runnable.Suggested resilience patch
const sessionRes = await fetch("/api/nango-session", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ userId: "user_123" }), // replace with your actual user ID }); +if (!sessionRes.ok) { + throw new Error("Failed to create Nango session"); +} const { token } = await sessionRes.json(); const nango = new Nango({ connectSessionToken: token }); // Use the exact integration slug from your Nango dashboard const result = await nango.auth("<your-integration-slug>"); // result.connectionId is what you pass to your task -await fetch("/api/analyze-prs", { +const analyzeRes = await fetch("/api/analyze-prs", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ connectionId: result.connectionId, repo: "triggerdotdev/trigger.dev", }), }); +if (!analyzeRes.ok) { + throw new Error("Failed to trigger analyze-prs task"); +}As per coding guidelines, "Code examples must be complete and runnable where possible".
Also applies to: 125-132
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/guides/frameworks/nango.mdx` around lines 113 - 119, The fetch example assumes successful responses; change the session fetch (sessionRes) and the subsequent fetch call to first check response.ok (or status) before calling res.json(), and handle non-OK responses (throw or surface an error) so token/payload isn't read from a failed response; wrap the sequence in a try/catch and surface a clear error message to the user or console. Ensure you update the code paths that use sessionRes and token (and the later fetch/payload handling referenced around lines 125-132) so they only run after successful responses.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/guides/frameworks/nango.mdx`:
- Line 71: Replace nonstandard code-fence language tags in
docs/guides/frameworks/nango.mdx: change occurrences of "```ts" and "```tsx" to
"```typescript" for the affected snippets (specifically the fences that
currently read "```ts app/api/nango-session/route.ts", "```tsx app/page.tsx",
"```ts trigger/analyze-prs.ts", and "```ts app/api/analyze-prs/route.ts", plus
the other instances at lines ~105, 154, 229). Update each opening fence so the
language tag is "typescript" while leaving the file path portion intact.
---
Nitpick comments:
In `@docs/guides/frameworks/nango.mdx`:
- Line 286: The sentence suggesting to change "github" to other providers is
ambiguous about whether it expects a provider name or an integration slug;
update the guidance to explicitly state that you should replace the placeholder
with your Nango integration slug (e.g., "<your-integration-slug>") and give
provider-name examples ("github", "hubspot", "slack", "notion") to show the
difference so readers use their configured integration slug rather than an
arbitrary provider string.
- Around line 113-119: The fetch example assumes successful responses; change
the session fetch (sessionRes) and the subsequent fetch call to first check
response.ok (or status) before calling res.json(), and handle non-OK responses
(throw or surface an error) so token/payload isn't read from a failed response;
wrap the sequence in a try/catch and surface a clear error message to the user
or console. Ensure you update the code paths that use sessionRes and token (and
the later fetch/payload handling referenced around lines 125-132) so they only
run after successful responses.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 97a9dc06-40c8-4be5-b3ba-24baef21a11d
📒 Files selected for processing (1)
docs/guides/frameworks/nango.mdx
📜 Review details
🧰 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,json
Files:
docs/guides/frameworks/nango.mdx
🧠 Learnings (3)
📓 Common learnings
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3200
File: docs/config/config-file.mdx:353-368
Timestamp: 2026-03-10T12:44:19.869Z
Learning: In the triggerdotdev/trigger.dev repository, docs PRs are often written as companions to implementation PRs (e.g., PR `#3200` documents features being added in PR `#3196`). When reviewing docs PRs, the documented features may exist in a companion/companion PR branch rather than main. Always check companion PRs referenced in the PR description before flagging missing implementations.
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: packages/cli-v3/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:34.140Z
Learning: Keep SDK documentation in `rules/` and `.claude/skills/trigger-dev-tasks/` synchronized when features are added or changed
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2026-03-02T12:43:02.539Z
Learning: New documentation pages must be added to the navigation structure in `docs.json` under the correct group after creating the MDX file
📚 Learning: 2025-11-27T16:27:35.304Z
Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Use `TriggerAuthContext` provider to supply Public Access Token to Trigger.dev React hooks
Applied to files:
docs/guides/frameworks/nango.mdx
📚 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/guides/frameworks/nango.mdx
🪛 LanguageTool
docs/guides/frameworks/nango.mdx
[uncategorized] ~286-~286: The official name of this software platform is spelled with a capital “H”.
Context: ...rks for any Nango-supported API. Change "github" to "hubspot", "slack", "notion"...
(GITHUB)
1 participant
Adds a guide showing how to use Nango to make authenticated API calls inside a Trigger.dev task, using GitHub + Claude as a concrete example.