feat(webapp): deprecate v3 CLI deploys server-side#3415
Conversation
Detect deploys coming from v3 CLI versions (payloads that omit the
'type' field) and, when DEPRECATE_V3_CLI_DEPLOYS_ENABLED=1, reject them
with a clear error that points to the migration docs. Enforcement is
gated so we can observe v3 deploy traffic via logs before flipping.
v4 CLIs always send 'type' ('MANAGED' or 'V1') on /api/v1/deployments,
so they are unaffected. Verified against the CLI source for 4.0.0,
4.0.1, 4.0.5, 4.1.0, 4.2.0, and 4.4.4.
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
WalkthroughThe pull request introduces a server-side deprecation gate for v3 CLI deploys. A new environment variable Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/webapp/app/v3/services/initializeDeployment.server.ts (1)
28-82:⚠️ Potential issue | 🟠 MajorMove the v3 gate before the legacy deployment shortcut.
Line 29 can return before Line 67, so a missing-
typerequest withgitMeta.commitShastarting with"deployment_"bypasses both the warning and enforcement. Put the gate first so detection always runs.🐛 Proposed fix
return this.traceWithEnv("call", environment, async () => { + // v4 CLI versions always send `payload.type` ("MANAGED" or "V1"). v3 CLI + // versions never do, so the absence of `type` is a reliable signal that + // the request came from a 3.x CLI. Detection always runs (so we can + // observe how many deploys are still using v3), enforcement is gated + // behind DEPRECATE_V3_CLI_DEPLOYS_ENABLED so it can be rolled out safely. + if (!payload.type) { + const enforced = env.DEPRECATE_V3_CLI_DEPLOYS_ENABLED === "1"; + + logger.warn("Detected deploy from deprecated v3 CLI", { + environmentId: environment.id, + projectId: environment.projectId, + organizationId: environment.project.organizationId, + enforced, + }); + + if (enforced) { + throw new ServiceValidationError( + "The trigger.dev CLI v3 is no longer supported for deployments. Please upgrade your project to v4: https://trigger.dev/docs/migrating-from-v3" + ); + } + } + if (payload.gitMeta?.commitSha?.startsWith("deployment_")) { // When we introduced automatic deployments via the build server, we slightly changed the deployment flow // mainly in the initialization and starting step: now deployments are first initialized in the `PENDING` status @@ }; } - - // v4 CLI versions always send `payload.type` ("MANAGED" or "V1"). v3 CLI - // versions never do, so the absence of `type` is a reliable signal that - // the request came from a 3.x CLI. Detection always runs (so we can - // observe how many deploys are still using v3), enforcement is gated - // behind DEPRECATE_V3_CLI_DEPLOYS_ENABLED so it can be rolled out safely. - if (!payload.type) { - const enforced = env.DEPRECATE_V3_CLI_DEPLOYS_ENABLED === "1"; - - logger.warn("Detected deploy from deprecated v3 CLI", { - environmentId: environment.id, - projectId: environment.projectId, - organizationId: environment.project.organizationId, - enforced, - }); - - if (enforced) { - throw new ServiceValidationError( - "The trigger.dev CLI v3 is no longer supported for deployments. Please upgrade your project to v4: https://trigger.dev/docs/migrating-from-v3" - ); - } - } if (payload.type === "UNMANAGED") {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/webapp/app/v3/services/initializeDeployment.server.ts` around lines 28 - 82, The v3-deprecation detection (the if (!payload.type) block using env.DEPRECATE_V3_CLI_DEPLOYS_ENABLED, logger.warn and ServiceValidationError) must run before the legacy shortcut that returns an existing deployment when payload.gitMeta.commitSha startsWith("deployment_"); move the entire "if (!payload.type) { ... }" block to immediately after entering the traceWithEnv("call", environment, async () => { ... }) callback and before the "if (payload.gitMeta?.commitSha?.startsWith('deployment_'))" branch so missing-type requests cannot bypass the warning/enforcement while preserving existing logging and error behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/webapp/app/env.server.ts`:
- Around line 351-355: The env var schema uses z.string().default("0") for
DEPRECATE_V3_CLI_DEPLOYS_ENABLED which accepts typos like "true" or "1 "; change
the validator to z.enum(["0","1"]).default("0") so only the exact values "0" or
"1" are allowed, update any related type usages or destructuring that rely on
the old string type if necessary, and keep the same default semantics to ensure
enforcement toggles behave deterministically (refer to the
DEPRECATE_V3_CLI_DEPLOYS_ENABLED symbol in env.server.ts).
---
Outside diff comments:
In `@apps/webapp/app/v3/services/initializeDeployment.server.ts`:
- Around line 28-82: The v3-deprecation detection (the if (!payload.type) block
using env.DEPRECATE_V3_CLI_DEPLOYS_ENABLED, logger.warn and
ServiceValidationError) must run before the legacy shortcut that returns an
existing deployment when payload.gitMeta.commitSha startsWith("deployment_");
move the entire "if (!payload.type) { ... }" block to immediately after entering
the traceWithEnv("call", environment, async () => { ... }) callback and before
the "if (payload.gitMeta?.commitSha?.startsWith('deployment_'))" branch so
missing-type requests cannot bypass the warning/enforcement while preserving
existing logging and error behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 432279cb-11c5-4d8c-ab69-3067d52d16a4
📒 Files selected for processing (3)
.server-changes/deprecate-v3-cli-deploys.mdapps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
📜 Review details
⏰ 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). (27)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: sdk-compat / Deno Runtime
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
- GitHub Check: sdk-compat / Bun Runtime
- GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
- GitHub Check: sdk-compat / Cloudflare Workers
- GitHub Check: typecheck / typecheck
🧰 Additional context used
📓 Path-based instructions (8)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Use types over interfaces for TypeScript
Avoid using enums; prefer string unions or const objects instead
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use zod for validation in packages/core and apps/webapp
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Use function declarations instead of default exports
Add crumbs as you write code using
//@Crumbscomments or `// `#region` `@crumbsblocks. These are temporary debug instrumentation and must be stripped usingagentcrumbs stripbefore merge.
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
**/*.ts: When creating or editing OTEL metrics (counters, histograms, gauges), ensure metric attributes have low cardinality by using only enums, booleans, bounded error codes, or bounded shard IDs
Do not use high-cardinality attributes in OTEL metrics such as UUIDs/IDs (envId, userId, runId, projectId, organizationId), unbounded integers (itemCount, batchSize, retryCount), timestamps (createdAt, startTime), or free-form strings (errorMessage, taskName, queueName)
When exporting OTEL metrics via OTLP to Prometheus, be aware that the exporter automatically adds unit suffixes to metric names (e.g., 'my_duration_ms' becomes 'my_duration_ms_milliseconds', 'my_counter' becomes 'my_counter_total'). Account for these transformations when writing Grafana dashboards or Prometheus queries
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
**/*.{js,ts,jsx,tsx,json,md,yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
Format code using Prettier before committing
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
**/*.ts{,x}
📄 CodeRabbit inference engine (CLAUDE.md)
Always import from
@trigger.dev/sdkwhen writing Trigger.dev tasks. Never use@trigger.dev/sdk/v3or deprecatedclient.defineJob.
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: Access environment variables through theenvexport ofenv.server.tsinstead of directly accessingprocess.env
Use subpath exports from@trigger.dev/corepackage instead of importing from the root@trigger.dev/corepathUse named constants for sentinel/placeholder values (e.g.
const UNSET_VALUE = '__unset__') instead of raw string literals scattered across comparisons
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
apps/webapp/**/*.server.ts
📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
apps/webapp/**/*.server.ts: Never userequest.signalfor detecting client disconnects. UsegetRequestAbortSignal()fromapp/services/httpAsyncStorage.server.tsinstead, which is wired directly to Expressres.on('close')and fires reliably
Access environment variables viaenvexport fromapp/env.server.ts. Never useprocess.envdirectly
Always usefindFirstinstead offindUniquein Prisma queries.findUniquehas an implicit DataLoader that batches concurrent calls and has active bugs even in Prisma 6.x (uppercase UUIDs returning null, composite key SQL correctness issues, 5-10x worse performance).findFirstis never batched and avoids this entire class of issues
Files:
apps/webapp/app/env.server.tsapps/webapp/app/v3/services/initializeDeployment.server.ts
🔇 Additional comments (1)
.server-changes/deprecate-v3-cli-deploys.md (1)
1-6: LGTM.The server-change note clearly documents the breaking deployment behavior and rollout flag.
2 participants
✅ Checklist
Summary
Adds a server-side gate that detects deploy attempts from v3 CLI versions (i.e.
trigger.dev@3.x) at thePOST /api/v1/deploymentsentry point and, when enabled, rejects them with a clear upgrade message. v4 CLI deploys are completely unaffected.The last 3.x CLI release was
3.3.7, which we can't update. This approach short-circuits the deploy before any DB writes, image-ref generation, S2 stream creation, or queue enqueue — no side effects in either mode.How v3 vs v4 are distinguished
I pulled the published CLI tarballs for
trigger.dev@3.3.7,4.0.0,4.0.1,4.0.5,4.1.0,4.2.0, and the current4.4.4in the repo. The cleanest, most reliable signal is the request body toPOST /api/v1/deployments:type"MANAGED"(run_engine_v2) or"V1"isNativeBuild/gitMeta/triggeredVia/runtimeregistryHost/namespaceEvery v4 call site I inspected sets
type: features.run_engine_v2 ? "MANAGED" : "V1"unconditionally.payload.typeisundefinedif and only if the client is a 3.x CLI.Behavior
Detection always runs and emits
logger.warn("Detected deploy from deprecated v3 CLI", { environmentId, projectId, organizationId, enforced }), which lets us watch how many v3 deploys are still happening before enforcement is flipped.Enforcement is gated behind
DEPRECATE_V3_CLI_DEPLOYS_ENABLED(default"0", off). When"1", the server returns400with:The v3 CLI surfaces this verbatim as
Failed to start deployment: <message>becausezodfetchthrowsApiErrorfor non-retryable 4xx (400/422) anddeploy.jsin 3.3.7 printserror.message.Out of scope (intentionally)
api.v1.deployments.$deploymentId.finalize.ts/FinalizeDeploymentService/createDeploymentBackgroundWorkerV3.server.tsare V1-engine paths, not the v3 CLI gate. Leaving them alone per review.createDeploymentBackgroundWorkercall inmanaged-index-controller.tsis still used by v4's in-image indexer. Not touched.trigger devflow (different code path) — separate deprecation if/when needed.Testing
pnpm run typecheck --filter webapplocally — passes.type:in theinitializeDeploymentcall site, so none will be accidentally blocked.initializeDeploymentpayload has notypefield.Rollout plan after merge:
DEPRECATE_V3_CLI_DEPLOYS_ENABLEDunset → watchDetected deploy from deprecated v3 CLIlog volume.DEPRECATE_V3_CLI_DEPLOYS_ENABLED=1to enforce.Changelog
Detect v3 CLI deploys on
/api/v1/deploymentsand, whenDEPRECATE_V3_CLI_DEPLOYS_ENABLED=1, reject them with an upgrade message pointing at https://trigger.dev/docs/migrating-from-v3. v4 CLI deploys are unaffected.Link to Devin session: https://app.devin.ai/sessions/b242c11bd86e4099aeec8b59bab62143
Requested by: @ericallam