Resolve deployment compute config from routed version summaries

[rossnelson]

Description & motivation 💭

Follow-up to #3779, which added hasComputeConfig wrappers to hide serverless-only actions on the deployment page. The value is always false in Cloud, so "Create new version" and "Ramp to unversioned" are hidden for every deployment, including ones that do have scaling groups.

deploymentHasComputeConfig checked three fields:

deployment.computeConfig
deployment.currentVersionSummary?.computeConfig
deployment.rampingVersionSummary?.computeConfig

None of them exist on the DescribeWorkerDeployment response. WorkerDeploymentInfo (message.proto:184-212) carries only name, version_summaries, create_time, routing_config, last_modifier_identity, manager_identity, routing_config_update_state.

current_version_summary / ramping_version_summary / latest_version_summary are fields on ListWorkerDeployments' WorkerDeploymentSummary (request_response.proto:2333-2343). They leak onto the describe type through WorkerDeploymentInfo extends WorkerDeploymentSummary (types/deployments.ts:84, in place since #2576), so they type-check against a payload the server never sends them in. The list page uses them correctly — deployment-table-row.svelte:81 is a real list row.

An actual Cloud describe response — compute config is present, just on versionSummaries, with no currentVersionSummary key anywhere:

{
  "workerDeploymentInfo": {
    "name": "test",
    "versionSummaries": [
      {
        "deploymentVersion": { "buildId": "62a8974f-…", "deploymentName": "test" },
        "status": "WORKER_DEPLOYMENT_VERSION_STATUS_CURRENT",
        "computeConfig": { "scalingGroups": { "default": { "providerType": "aws-lambda" } } }
      }
    ],
    "routingConfig": {
      "currentDeploymentVersion": { "buildId": "62a8974f-…", "deploymentName": "test" }
    }
  }
}

Fix

Resolve the current and ramping summaries out of versionSummaries via routingConfig, matching on deploymentName + buildId the same way version-table-row.svelte:91-97 already does. lock-compute-provider.ts:48 also walks versionSummaries — this brings the two helpers in line.

The three old summary fields stay in the check so list-shaped input keeps working, and #3779's "ignore inactive versions" intent is preserved: compute config on a version that isn't routed to still returns false.

Testing 🧪

How was this tested 👻

• Unit tests added

The verbatim Cloud payload above is now a regression fixture. Verified it fails on the old helper (expected false to be true) and passes on the new one, so the test is doing real work.

• deployment-has-compute-config.test.ts — 11 pass (4 new: real Cloud payload, routed current, routed ramping, non-routed ignored)
• deployment.svelte.test.ts — 4 pass
• Deployments/workers component suites — 60 pass
• pnpm check — 38 errors, all pre-existing Cannot find module 'storybook/test' resolution failures, none in touched files

Steps for others to test: 🚶🏽‍♂️🚶🏽‍♀️

Open a Cloud worker deployment whose current version has a compute config. "Create new version" should appear next to More Actions, and "Ramp to unversioned" should be in the menu. On a self-hosted deployment with no scaling groups, both stay hidden.

Checklists

Merge Checklist

• Needs a repack into cloud-ui to land there (.ui-sha is currently 96a06250)

Follow-up (not in this PR)

WorkerDeploymentInfo extends WorkerDeploymentSummary is what let this through — the describe type advertises three fields the endpoint never returns. Splitting them would prevent a repeat, but it ripples into lock-compute-provider.ts and deployment-table-row.svelte, so it felt wrong to bundle with a fix.

Also unverified: top-level deployment.computeConfig (types/deployments.ts:86) isn't on either OSS message. Left in place as harmless, but I found nothing that populates it.

Docs

Any docs updates needed?

No.

Blast radius 🔍

deploymentHasComputeConfig has two consumers, and both read a describe response, so both were broken:

1. deployment.svelte:133 — the deployment page. The reported bug.
2. no-workers-polling-alert.svelte:42 — also fixed as a side effect, and this one is user-visible on workflow pages. serverlessDeployment was always false in Cloud, so it always fell through to the {:else} generic "no workers polling" warning. Cloud deployments with routed compute config now correctly get the serverless info alert with the "View worker deployment" link. Intended behavior for that component, but worth a look since it's outside Fix worker deployment actions for self-hosted deployments #3779's stated scope. Note it has no test file.

The deployments list page is not affected. It never calls this helper — deployment-table-row.svelte:80-82 reads currentVersionSummary?.computeConfig?.scalingGroups directly off a WorkerDeploymentSummary from ListWorkerDeployments, where that field really does exist.

The change is additive-only: entries appended to the existing .some() array, three original checks untouched and evaluated first. It can only flip false → true, so nothing that previously rendered can stop rendering.

Full suite: 2573 pass, 13 fail — all 13 are pre-existing timezone-dependent date/time tests that fail identically on main (verified), none deployment-related.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
holocene	Ready	Preview	Aug 4, 2026 11:24pm

[tegan-temporal]

just to double check, we actually want undefined values in the returned array? or should this check isVersionSummaryNew(summary) be part of the filter?