Workspace update fails for templates that use dynamic parameters

Inizia in src/api/updateParameters.ts, in collectUpdateParameters e promptSpec, quindi confronta la relativa gestione dei parametri legacy con gli endpoint dei parametri dinamici e i percorsi dei resolver collegati nell’issue. Determina quale mitigazione sia appropriata per l’estensione e verifica che gli aggiornamenti del workspace gestiscano i parametri obbligatori condizionali e le opzioni dinamiche, preservando il comportamento legacy.

Symptom

Updating a workspace from VS Code fails with a generic "resolve parameters" 400 error when the template uses dynamic parameters (the dynamic-parameters experiment, docs) and any of the following are true:

• A parameter is conditionally required based on another input value.
• A parameter only appears for certain combinations of other inputs (the static rich-parameters list does not include it).
• A parameter's options are computed dynamically (the static options list is empty or stale).

The user sees the failure as a build error in the workspace logs, with no clear indication that the workspace update endpoint expected additional or different parameter values than were provided.

Root cause

collectUpdateParameters (src/api/updateParameters.ts) calls getTemplateVersionRichParameters, which returns the static parameter list captured at template-version provisioning time (coderd/templateversions.go:287). It then mirrors the dashboard's legacy-params getMissingParameters check.

For templates using dynamic parameters, the dashboard takes a different path entirely:

• It opens a WebSocket at /api/v2/templateversions/{id}/dynamic-parameters?user_id=… (site/src/api/api.ts:1175).
• The server reactively re-renders the parameter form as the user types, evaluating coder_parameter conditionals against owner data, previous build values, and presets.
• On submit, the build endpoint calls wsbuilder.getDynamicParameters → dynamicparameters.ResolveParameters (coderd/wsbuilder/wsbuilder.go:881), which returns an hcl.Diagnostics error if any reactive constraint is unsatisfied.

The extension never opens that socket, so its prompt set is whatever the static list said at provisioning time. When the dynamic resolver evaluates the submitted build values and finds a conditionally-required parameter missing (or a dynamically-restricted option violated), the build fails.

Reproduction

1. Author a template with terraform-provider-coder v2.x declaring two parameters where the second is optional only when the first has a specific value (a typical reactive form), and enable the dynamic-parameters experiment on the deployment.
2. Create a workspace from that template, choosing values such that the conditional path requires the second parameter.
3. Update the template's active version (any change that keeps both parameters but does not alter the conditional logic).
4. From VS Code, run coder.updateWorkspace on the workspace.
5. Observe the build fails with a 400 "resolve parameters" error from wsbuilder. The extension shows a generic workspace-update-failed notification; the underlying diagnostic is only visible in the workspace logs.

Scope of impact

• Affected: any deployment with the dynamic-parameters experiment enabled (the path the Coder team is pushing as the default going forward).
• Not affected: deployments still on legacy/classic parameters — those continue to work with the existing needsPrompt logic.
• Partial impact: templates that enable dynamic parameters but never use any reactive constructs (no conditional required, no dynamic option lists, no conditionally-appearing parameters) update fine, because the static list happens to be accurate.

Proposed mitigations

In rough order of effort:

1. Detect and warn (S): read the template's use_classic_parameter_flow (or equivalent) flag in collectUpdateParameters. If false, surface a one-line warning telling the user to update via the dashboard (with a deep link) and skip the prompts. Currently we silently send incomplete data.
2. One-shot REST evaluate (M): call POST /api/v2/templateversions/{id}/dynamic-parameters/evaluate (coderd/parameters.go, api.ts:1155) with the current build parameters as inputs, feed the returned non-reactive parameter list into the existing promptSpec + QuickPick flow. Loses interactive reactivity but picks up server-evaluated required and option lists. Best ROI for most templates.
3. WebSocket + Webview (L): open /api/v2/templateversions/{id}/dynamic-parameters from the extension, render a reactive form in a Webview, send each answer back as the user fills it in. Closest to the dashboard UX but a real feature, not a fix. Existing reconnectingWebSocket.ts infra is reusable.

Related

• PR #967 (this PR): legacy-params drift detection and immutable-param prompting. Closes the legacy gap but explicitly does not address dynamic params; the JSDoc on promptSpec calls this out.
• The dashboard skips its getMissingParameters client-side check when isDynamicParametersEnabled is true (site/src/api/api.ts:2532) and relies entirely on the server resolver.