feat(cli): a version id resolves its service in one request - #235
Merged
Conversation
|
Warning Review limit reachedNext included review available in 24 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
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 |
wmadden
approved these changes
Aug 25, 2026
wmadden-electric
force-pushed
the
feat/deployment-owner-direct-lookup
branch
from
August 25, 2026 15:13
69c1af0 to
df50db4
Compare
commit: |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
wmadden-electric
force-pushed
the
feat/deployment-owner-direct-lookup
branch
from
August 25, 2026 15:21
df50db4 to
c5efaf0
Compare
wmadden
pushed a commit
that referenced
this pull request
Aug 26, 2026
…236) ## Purpose of change `@prisma/cli-engine` hands the shell a Management API client through `ctx.api`, and re-exports the SDK's type for it: ```ts // packages/cli-engine/src/management-api.ts /** The SDK's typed client, re-exported so consumers never import * @prisma/management-api-sdk directly. */ export type ManagementApiClient = SdkClient; ``` That type belongs to `@prisma/management-api-sdk`, and until now the engine held that package as an ordinary dependency at an exact version — as did `packages/cli` and `packages/prisma`, each independently: ``` cli-engine dependencies: @prisma/management-api-sdk = 1.55.0 cli dependencies: @prisma/management-api-sdk = 1.55.0 prisma dependencies: @prisma/management-api-sdk = 1.55.0 ``` A package whose public API carries another package's types has a shared type surface. Held as three private copies, the three pins can disagree — and when they disagree, the types stop being the same type. Moving only the shell to a newer SDK produces this, roughly fifteen times over: ``` src/commands/branch/list.ts(80,9): error TS2345: Argument of type 'Client<paths@1.55.0>' is not assignable to parameter of type 'Client<paths@1.69.0>' ``` So the SDK version could only ever move in all three manifests at once. One of the three is the engine, and a changed engine needs a new engine version, and both `@prisma/composer-cli` and `@prisma/orm-toolchain` peer-pin the engine **exactly** — so an SDK bump, a routine act, cost a three-repo release sequence every time. That is what blocked #235 from taking `@prisma/management-api-sdk@1.69.0`, the version `@prisma/compute-sdk@0.42.0` asks for. ## What's changed The engine now declares the SDK the way a shared type surface should be declared: - **`cli-engine`**: `@prisma/management-api-sdk` moves from `dependencies` to `peerDependencies` at `^1.55.0` — a range, not a pin, because the consumer chooses. It stays in `devDependencies` at the version the workspace supplies so the package still builds and tests standalone. - **`cli` and `prisma`** keep it as a real dependency and move to `1.69.0`. They are the binaries; they install the one copy everyone binds to. All three packages now resolve `@prisma+management-api-sdk@1.69.0`, and `pnpm peers check` no longer reports compute-sdk's unmet peer. - **Engine `0.2.3` → `0.3.0`**, the pre-1.0 breaking slot: consumers of the published engine must now supply the SDK themselves. After this, moving the SDK touches the two app manifests and nothing else — no engine version, no family republish. ## The transition this starts The engine must publish before a family can peer it, so both families still declare `0.2.3` and conformance reports six pin mismatches. `packages/cli/scripts/conformance.ts` has a place for exactly this, and its comment prescribes the sequence; both entries are filled in with a `removeWhen`: ``` 0 failing, 6 allowed, 5 subject(s) checked ``` Every one prints in full with its reason, including the two copies of the engine that resolve in the sandbox install — the expected shape of a transition rather than a defect. The remaining steps, recorded in the deferred ledger: engine 0.3.0 publishes → both families republish peering 0.3.0 → a release PR here pins them and deletes the two exceptions, restoring the empty list. Verified: `pnpm typecheck`, `pnpm --filter @prisma/cli test` (958 passed), `pnpm check:conformance` (0 failing), `node scripts/check-engine-version.mjs`. ## Alternatives considered - **Relax `@prisma/compute-sdk`'s peer floor back to `^1.44.0`.** This was my first proposal and it was wrong. That floor is the one peer dependency in the picture that already works: it correctly reported that this repo was pinned behind. Widening it would have silenced an accurate warning and left the actual cause — three private copies of a shared type — in place. - **Bump all three manifests to 1.69.0 and take the release chain.** Fixes today's mismatch and leaves the next one to cost exactly the same. The same engine bump buys the structural fix instead. - **A `pnpm` override forcing one SDK version.** Makes the workspace green while the published engine still declares a version it does not get, so anyone installing `@prisma/cli-engine` alongside `@prisma/compute-sdk` reproduces the two-copy break. It hides the problem precisely where it would be felt. - **An exact peer (`1.69.0`) rather than a range.** Recreates the lockstep-bump problem one layer up: every SDK release would force an engine release again. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose of change
Every command that names a version by id —
prisma service version show|promote|start|stop|delete <id>— used to search the whole workspace for the service that owns it. Now it asks once:Version ids are globally unique, so
prisma service version show ver_abc123needs no service, project, or branch parameter. But the CLI still had to know the owning service — it prints the service name, and the promoted URL is the service's address rather than the version's preview domain. Until now the API's version response carried no owner pointer, so the only way to find it was to look everywhere: list every project, list every service in each project, then check each service's versions for the id. A workspace with 15 projects of 4 services each cost up to 75 requests to answer "who owns this version?".What's changed
The Management API now returns the owner, and this PR consumes it.
GET /v1/deployments/{id}gained aserviceIdfield (pdp-control-plane#4983),@prisma/compute-sdk@0.42.0exposes it asDeploymentDetail.serviceId(project-compute#174), andshowDeploymentin the app provider follows it straight toshowApp.findAppForDeploymentandfindServiceAppForDeploymentare gone — 76 lines, and with them the file'snoAwaitInLoopslint exemption, which existed only for those loops.nullfor both "no such service" and "id not found anywhere", which is whatSERVICE.VERSION_DETACHEDreported. The direct lookup can only see one of those: a 404 fromshowApp, meaning the service was deleted between the two calls. Any other error propagates instead of being flattened into "detached", so a network failure no longer masquerades as a missing service.@prisma/compute-sdk0.39.0 → 0.42.0, and@prisma/management-api-sdk1.55.0 → 1.69.0 acrosscli,prisma, andcli-engine— 1.69.0 is compute-sdk's peer floor and the first release whose types carry the field.The test kit's version fixtures gained
serviceId, which is what makes the new path honest: its fakeGET /v1/apps/{appId}answers any id, so without a fixture carrying the real owner id the assertion would pass no matter which id the CLI looked up.Verified:
pnpm typecheck,pnpm --filter @prisma/cli test(934 passed),pnpm --filter @prisma/compute test(11 passed). The e2e suite needsPRISMA_E2E_SERVICE_TOKEN, which this machine does not hold — thepull_requestrun on this PR is the real check.Alternatives considered
serviceIdis absent. Rejected: the field is required in the API contract and the SDK types it non-optional, so the fallback would be unreachable code carrying 76 lines and a lint exemption. An older server is a version-skew problem, and the SDK peer floor is where that is already handled.showAppas an error rather than a detached version. Rejected: it would turn a routine race (deleting a service while a version command is in flight) into a failure with no actionable message.SERVICE.VERSION_DETACHEDalready describes exactly that state.Closes the ledger entry "
GET /v1/deployments/{id}omits the parentappId" in.drive/projects/prisma-cli-v8/deferred.md.🤖 Generated with Claude Code