docs: add list deployments endpoint, fix defaultMachine, and clarify wait token browser completion #3350
docs: add list deployments endpoint, fix defaultMachine, and clarify wait token browser completion #3350
Conversation
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
WalkthroughDocumentation-only changes: in a config example Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 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 |
…/triggerdotdev/trigger.dev into docs/wait-for-token-browser-cors
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/v3-openapi.yaml (1)
923-926: Use a clearly non-secret placeholder in the curl auth sample.
tr_dev_1234is likely illustrative, but using an explicit placeholder avoids secret-scanner noise and copy/paste confusion.✏️ Suggested tweak
- lang: curl source: |- curl -X GET "https://api.trigger.dev/api/v1/deployments" \ - -H "Authorization: Bearer tr_dev_1234" + -H "Authorization: Bearer <TRIGGER_SECRET_KEY>"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/v3-openapi.yaml` around lines 923 - 926, The curl example in the OpenAPI docs uses a realistic-looking token ("-H \"Authorization: Bearer tr_dev_1234\"") which can trigger secret scanners; update the Authorization header in the curl sample (the block containing curl -X GET "https://api.trigger.dev/api/v1/deployments") to use a clearly non-secret placeholder such as "Authorization: Bearer YOUR_API_KEY" or "Authorization: Bearer <API_KEY>" instead of tr_dev_1234 so readers won’t accidentally paste a real token and scanners won’t flag it.
🤖 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/v3-openapi.yaml`:
- Around line 923-926: The curl example in the OpenAPI docs uses a
realistic-looking token ("-H \"Authorization: Bearer tr_dev_1234\"") which can
trigger secret scanners; update the Authorization header in the curl sample (the
block containing curl -X GET "https://api.trigger.dev/api/v1/deployments") to
use a clearly non-secret placeholder such as "Authorization: Bearer
YOUR_API_KEY" or "Authorization: Bearer <API_KEY>" instead of tr_dev_1234 so
readers won’t accidentally paste a real token and scanners won’t flag it.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5be99f6f-185a-43f2-8e6f-4dc26c928ba1
📒 Files selected for processing (2)
docs/v3-openapi.yamldocs/wait-for-token.mdx
✅ Files skipped from review due to trivial changes (1)
- docs/wait-for-token.mdx
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
docs/v3-openapi.yaml
🧠 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.
📚 Learning: 2026-01-28T14:15:15.011Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2953
File: apps/webapp/app/components/runs/v3/SharedFilters.tsx:441-452
Timestamp: 2026-01-28T14:15:15.011Z
Learning: In apps/webapp/app/components/runs/v3/SharedFilters.tsx, the maxPeriodDays limit for date ranges should only check the from date (via dateRangeToDays(fromValue)) because it enforces data retention limits—how far back in history queries can reach. The to date is irrelevant for retention-based limits.
Applied to files:
docs/v3-openapi.yaml
📚 Learning: 2026-03-26T10:00:07.558Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 3254
File: packages/cli-v3/src/apiClient.ts:61-86
Timestamp: 2026-03-26T10:00:07.558Z
Learning: In triggerdotdev/trigger.dev, the `api.v1.platform-notifications` loader filters `PlatformNotification` records by `surface: "CLI"` before returning them. As a result, `card` and `changelog` notification types (which are `WEBAPP`-only) never reach the CLI endpoint, and the `CliPlatformNotificationResponseSchema` in `packages/cli-v3/src/apiClient.ts` does not need to include those types in its `data.type` enum. Do not flag missing `card`/`changelog` enum values in this schema as a bug.
Applied to files:
docs/v3-openapi.yaml
🪛 Betterleaks (1.1.1)
docs/v3-openapi.yaml
[high] 923-926: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
🔇 Additional comments (1)
docs/v3-openapi.yaml (1)
787-909: Nice addition—this endpoint doc block is coherent and now aligned with prior pagination/filter fixes.
list_deployments_v1is well-scoped, and the updated constraints/notes (includingpage[size],tobehavior, enum parity, and pagination cursor semantics) read consistently.
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/v3-openapi.yaml (1)
810-819:⚠️ Potential issue | 🟠 MajorInclude
INSTALLINGin both deployment status enums.Line 812-819 and Line 874-881 omit
"INSTALLING", but deployment status enums for related endpoints include it. This can create divergent generated types and client-side parsing issues.🔧 Proposed fix
- in: query name: status schema: type: string enum: [ "PENDING", + "INSTALLING", "BUILDING", "DEPLOYING", "DEPLOYED", "FAILED", "CANCELED", "TIMED_OUT", ] @@ status: type: string enum: [ "PENDING", + "INSTALLING", "BUILDING", "DEPLOYING", "DEPLOYED", "FAILED", "CANCELED", "TIMED_OUT", ]Also applies to: 873-881
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/v3-openapi.yaml` around lines 810 - 819, Add the missing "INSTALLING" value to both deployment status enum blocks so generated types remain consistent; locate the deployment status enum definitions (the enum arrays containing "PENDING","BUILDING","DEPLOYING","DEPLOYED","FAILED","CANCELED","TIMED_OUT") and insert "INSTALLING" into each array in the docs/v3-openapi.yaml so all endpoints use the same set of statuses.
🧹 Nitpick comments (1)
docs/v3-openapi.yaml (1)
827-830: Adddate-timeformat tofromandtoquery params.Line 830 and Line 835 describe ISO 8601 values, but the schema only declares plain strings. Adding
format: date-timeimproves spec clarity and client generation quality.🛠️ Proposed improvement
- in: query name: from schema: type: string + format: date-time description: Filter deployments created on or after this date (ISO 8601). - in: query name: to schema: type: string + format: date-time description: Filter deployments created on or before this date (ISO 8601). Only applied when `from` is also provided.Also applies to: 832-835
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/v3-openapi.yaml` around lines 827 - 830, The OpenAPI parameter schemas for the query params named "from" and "to" currently only declare type: string but describe ISO 8601 dates; update both parameter schemas (the "from" and "to" query param definitions) to include format: date-time so clients and validators treat them as RFC 3339/ISO-8601 datetimes; ensure the change is applied to both occurrences noted in the diff (the "from" block and the "to" block).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/v3-openapi.yaml`:
- Around line 810-819: Add the missing "INSTALLING" value to both deployment
status enum blocks so generated types remain consistent; locate the deployment
status enum definitions (the enum arrays containing
"PENDING","BUILDING","DEPLOYING","DEPLOYED","FAILED","CANCELED","TIMED_OUT") and
insert "INSTALLING" into each array in the docs/v3-openapi.yaml so all endpoints
use the same set of statuses.
---
Nitpick comments:
In `@docs/v3-openapi.yaml`:
- Around line 827-830: The OpenAPI parameter schemas for the query params named
"from" and "to" currently only declare type: string but describe ISO 8601 dates;
update both parameter schemas (the "from" and "to" query param definitions) to
include format: date-time so clients and validators treat them as RFC
3339/ISO-8601 datetimes; ensure the change is applied to both occurrences noted
in the diff (the "from" block and the "to" block).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 6775c80a-90ab-4f44-a2c4-3391fe6ffc6e
📒 Files selected for processing (1)
docs/v3-openapi.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
docs/v3-openapi.yaml
🧠 Learnings (6)
📓 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-01-28T14:15:15.011Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 2953
File: apps/webapp/app/components/runs/v3/SharedFilters.tsx:441-452
Timestamp: 2026-01-28T14:15:15.011Z
Learning: In apps/webapp/app/components/runs/v3/SharedFilters.tsx, the maxPeriodDays limit for date ranges should only check the from date (via dateRangeToDays(fromValue)) because it enforces data retention limits—how far back in history queries can reach. The to date is irrelevant for retention-based limits.
Applied to files:
docs/v3-openapi.yaml
📚 Learning: 2026-03-26T10:00:07.558Z
Learnt from: 0ski
Repo: triggerdotdev/trigger.dev PR: 3254
File: packages/cli-v3/src/apiClient.ts:61-86
Timestamp: 2026-03-26T10:00:07.558Z
Learning: In triggerdotdev/trigger.dev, the `api.v1.platform-notifications` loader filters `PlatformNotification` records by `surface: "CLI"` before returning them. As a result, `card` and `changelog` notification types (which are `WEBAPP`-only) never reach the CLI endpoint, and the `CliPlatformNotificationResponseSchema` in `packages/cli-v3/src/apiClient.ts` does not need to include those types in its `data.type` enum. Do not flag missing `card`/`changelog` enum values in this schema as a bug.
Applied to files:
docs/v3-openapi.yaml
📚 Learning: 2026-03-22T19:34:22.737Z
Learnt from: matt-aitken
Repo: triggerdotdev/trigger.dev PR: 3187
File: apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.errors._index/route.tsx:99-103
Timestamp: 2026-03-22T19:34:22.737Z
Learning: In `apps/webapp/app/presenters/v3/ErrorsListPresenter.server.ts`, the `statuses` filter (UNRESOLVED | RESOLVED | IGNORED) is applied in-memory after the ClickHouse query and a batch Postgres lookup via `getErrorGroupStates`. This is intentional: `status` lives in the Postgres `ErrorGroupState` table, not in ClickHouse, so post-query filtering is the correct approach. Do not flag this as a missing predicate or a no-op filter during code review.
Applied to files:
docs/v3-openapi.yaml
📚 Learning: 2026-03-13T13:42:59.104Z
Learnt from: ericallam
Repo: triggerdotdev/trigger.dev PR: 3213
File: apps/webapp/app/routes/admin.api.v1.llm-models.$modelId.ts:40-43
Timestamp: 2026-03-13T13:42:59.104Z
Learning: In `apps/webapp/app/routes/admin.api.v1.llm-models.$modelId.ts` and `apps/webapp/app/routes/admin.api.v1.llm-models.ts`, the `startDate` field in `UpdateModelSchema` and `CreateModelSchema` intentionally uses `z.string().optional()` (or `.nullable().optional()`) without strict ISO datetime validation. Invalid date strings are rejected at the Prisma/DB layer. This is acceptable because these are admin-only API routes protected by Personal Access Token (PAT) authentication and are not user-facing.
Applied to files:
docs/v3-openapi.yaml
📚 Learning: 2026-03-29T19:16:38.123Z
Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 3291
File: apps/webapp/app/v3/featureFlags.ts:53-65
Timestamp: 2026-03-29T19:16:38.123Z
Learning: In Zod v3 (including 3.25.x used in triggerdotdev/trigger.dev), `z.coerce.boolean()` returns a `ZodBoolean` instance directly — its `_def.typeName` is `"ZodBoolean"`, NOT `"ZodEffects"`. Only `.preprocess()`, `.refine()`/`.superRefine()`, and `.transform()` wrap schemas in `ZodEffects`. Do NOT flag `getFlagControlType` in `apps/webapp/app/v3/featureFlags.ts` for failing to unwrap `ZodEffects` when handling `z.coerce.*` schemas.
Applied to files:
docs/v3-openapi.yaml
🪛 Betterleaks (1.1.1)
docs/v3-openapi.yaml
[high] 921-924: Discovered a potential authorization token provided in a curl command header, which could compromise the curl accessed resource.
(curl-auth-header)
🔇 Additional comments (1)
docs/v3-openapi.yaml (1)
799-805: Good alignment with endpoint behavior.Line 802-805, Line 835, and Line 901 now correctly document page-size minimums,
todependency onfrom, and omission ofpagination.nextwhen exhausted.Also applies to: 832-835, 899-901
Adds missing list deployments API page, fixes defaultMachine → machine in config docs, and clarifies browser CORS usage for wait token completion with corrected warning placement