We shall fix this!

cc @mtojek

Taking a look

I reproduced a bit different issue, but I believe that the root cause is the same.

What I did is:

1. Create a new template. It doesn't need to use variables for now.
2. Create a workspace using the above template.
3. Set the autostop TTL=300s using API.
4. Push a new template revision with the new required variable (no default):

variable "region2" {
  description = "This is region."
  type        = string
}

5. Wait for the autostop to kick-off:

Root cause: it seems to be related to the template version that is used. For some reason (a bug?), autostop uses the latest template version instead of the one that is assigned before the autostop event.

Context: #6049 modified the autostart behaviour to automatically update the workspace to the latest template version. Previously, it would use the template version of the last successful build.

@bpmct It seems that we have conflicting assumptions. Do you think that we should revert the auto-update? Otherwise, it will be either confusing for users ("did it update or not") or it will keep failing.

I see. Why are we updating the version on stop instead of the next start?

I guess we can disable the "auto-update" behavior for now, but I know some users are hoping to use Coder to ensure developers all stay on the same version. The behavior I would (eventually) expect is:

• Coder auto stops workspace with existing version
• During auto start, Coder attempts to use new version
• If there are new parameters, a developer will be notified when they SSH, visit via VS Code, or on the dashboard that they need to set new values for the workspace to start.
• A template admin can disable auto-updating and also allow developers to switch to any version of a template they'd like.

Seems like this would require significant rework though, so let's revert the auto-update for now.

FYI "Autoupdate" has been reverted.

I guess that I can close it now.