Repository navigation
bug: workspace deadlock with invalid parameter & automatic updates set #19676
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
a customer reported this bug, & i asked Blink to write up the below report:
I've identified the bug location! This is a critical UX deadlock in the workspace parameters flow.
Root Cause:
The bug is in/site/src/pages/WorkspaceSettingsPage/WorkspaceParametersPage/WorkspaceParametersForm.tsxat lines 75-78:const disabled = workspace.outdated && workspace.template_require_active_version && !canChangeVersions;The Problem:
- When
template_require_active_versionis enabled and the workspace is outdated- Users without
canChangeVersionspermission get the parameters form disabled- But they need to fix invalid parameters to update the template version
- This creates an impossible catch-22 situation
Where it manifests:
- The form shows: "The template for this workspace requires automatic updates. Update the workspace to edit parameters."
- But users can't update because invalid parameters block the template version update
- Same logic exists in the experimental version at line 75-78 of WorkspaceParametersPageViewExperimental.tsx
Related files:/site/src/modules/workspaces/actions.ts- handles the update actions/site/src/utils/workspace.tsx- contains automatic update policy logic/site/src/pages/WorkspacePage/WorkspaceNotifications/WorkspaceNotifications.tsx- shows update notificationsThe fix would need to allow parameter editing even when outdated &&
template_require_active_versionif there are validation errors preventing the update.
Relevant Log Output
Expected Behavior
users should be able to update their workspaces with a new parameter
Steps to Reproduce
- Set
template_require_active_versionwith an outdated workspace - Attempt to update the workspace
- Attempt to update parameters
Environment
- Host OS:
- Coder version:
Additional Context
No response
Activity
blinkagent commentedon Sep 23, 2026
Retested on v2.36.5 — still reproduces
Retested by adding a validation to one of the template's parameters and pushing a new version while the template has
require_active_versionenabled.Observed behaviour
A user with only the
Memberrole cannot edit any template parameter values for their workspace while Coder is forcing an update and restart. This happens on both entry paths:Notably, parameters that were not modified by the new template version are locked as well, not just the one with the new validation. The user has no way to supply a valid value, so the workspace cannot be started.
Confirmed still present in
mainandrelease/2.36The guard is unchanged, it has just moved files since this issue was filed. It now lives in
site/src/pages/WorkspaceSettingsPage/WorkspaceParametersPage/WorkspaceParametersPageView.tsx#L71-L74:Two details explain the symptoms above:
canChangeVersionsresolves topermissions.updateWorkspaceVersion, which is an authz check foraction: "update"on the template (site/src/modules/workspaces/permissions.ts#L29-L35). AMembernever satisfies this, only template admins and owners.disabledis OR'd into theisDisabledof every field and into the submit button (lines 254-258 and 283-295), which is why untouched parameters are locked too.Why the guard misfires here
The condition does not consider the
?templateVersionId=query param. Both entry paths above land on the page withworkspace.outdated === true, and the "Update and restart" path arrives withtemplateVersionIdalready set to the active version byWorkspaceUpdateDialogs.tsx#L181.In other words, the user is already targeting the active version, so the original intent of the guard from #11117 (prevent pinning parameter values onto a stale version) does not apply. The backend would accept the build; only the UI blocks it.
A fix likely needs to scope
disabledso it does not apply when the form is already targeting the template's active version.fix(site): use the active version on the parameters page when it is r…