Prefill the deploy endpoint, redeploy suspended deployments, and scope-gate the deploy page - #3407
Prefill the deploy endpoint, redeploy suspended deployments, and scope-gate the deploy page#3407dakshina99 wants to merge 3 commits into
Conversation
…y detail Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…not work An undeployed deployment already read as "Suspended", but the row still offered "Stop deployment" — enabled, and certain to fail, since there was nothing left to stop. It now offers Redeploy, which restores that same deployment: the deployment is immutable, so the gateway gets back exactly what it was serving, with no build and no re-render. The row's single action is now chosen from the gateway's state rather than from one boolean: suspended restores the deployment, failed re-deploys its build (a new deployment), and serving stops. Only stopping is styled as destructive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The override replaces the built-in Deploy page, and with it the ScopeGate that page wraps itself in — so reaching Deploy from an organization- or project-level page ended at "Open an API within a project to deploy it." with no way forward. The sidebar shows the item at every scope, so getting there without an API in scope is a normal thing to do. Re-applying the gate gives that route the same project/API picker every other API-scoped page has, which navigates to the fully scoped URL. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (7)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe deployment UI now loads an API backend URL for initial deployments, supports redeploy actions for undeployed gateways, updates deployment dialog behavior, and restores API scope gating for the cloud plugin. ChangesDeployment flow
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk: 🟡 Moderate · up to The deployment dialog now prefills endpoints from the selected API. Switching APIs while that lookup is in flight can leave a prior API’s endpoint in the dialog, creating a risk of deploying to the wrong backend unless the response is scoped to the current API. Sequence Diagram(s)sequenceDiagram
participant GatewayRow
participant EnvironmentCard
participant DeployPage
participant DeployFeature
participant deployApi
GatewayRow->>EnvironmentCard: invoke onRedeploy
EnvironmentCard->>DeployPage: pass gatewayId
DeployPage->>DeployFeature: invoke onRedeployGateway
DeployFeature->>deployApi: POST deployment /redeploy
deployApi-->>DeployFeature: redeploy result
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Purpose
Three problems on the deploy plugin's page:
ScopeGateit wraps itself in.Plus two bits of detail shown where they mean nothing: a build id in the "Build and Deploy" dialog (the id of the previous build, while that dialog creates a new one), and an Endpoint URL viewer on gateways with nothing deployed.
Goals
upstream.main.url, so a first deploy needs no typing.Approach
Endpoint default.
deployApigainsreadApiEndpointUrl()(GET /rest-apis/{handle}→upstream.main.url).DeployFeaturereads it once per API — deliberately not insideload(), so it is not re-fetched by the 4-second settling poll — and a failure leaves the rest of the page working. Precedence in the dialog: what the user typed → what this gateway already serves → the API's endpoint → empty. A gateway already running something keeps its own endpoint, so a re-deploy never silently changes it.Redeploy. The row's single action is now derived from the gateway's state instead of one boolean: suspended restores the deployment (
POST .../deployments/{deploymentId}/redeploy), failed re-deploys its build as a new deployment, serving stops. Only stopping is styled destructive. Restoring relies on the deployment being immutable, so the gateway gets back exactly what it was serving — same build, same endpoint, nothing rendered.Scope gate. The
page.apiDeployoverride is wrapped inScopeGate requires="api" to={routes.apiDeploy}at the registration seam, matching the built-in page. Done there rather than inAppRoutesso the open-source route is untouched andScopeGate's dependencies stay out of the initial bundle, which that file explicitly guards.UNDEPLOYEDalready mapped to "Suspended" in the status vocabulary, so no change was needed there.Documentation
N/A — no new user-facing concepts; the deploy page's existing controls behave correctly rather than differently.
Automation tests
Security checks
Samples
Deploy page states: a gateway with nothing deployed shows no build id and no endpoint viewer; a suspended one shows Suspended with Redeploy; a serving one shows Active with Stop deployment.
Related PRs
Redeploy calls a
redeployroute on the deployment API the plugin talks to, which is added alongside this change; the rest is self-contained.Test environment
Node 24, Chrome, macOS (arm64).