@Emyrk can you talk about back compatibility and why you're not making this "type" field an enum (in the database and in the proto), or point to a design doc if one exists and I just missed it.

Also, I don't understand howform_type relates to#17892 which is about deleting workspaces.

@Emyrk can you talk about back compatibility and why you're not making this "type" field an enum (in the database and in the proto), or point to a design doc if one exists and I just missed it.

Also, I don't understand howform_type relates to#17892 which is about deleting workspaces.

The enum types are defined here:https://github.com/coder/terraform-provider-coder/blob/main/provider/formtype.go#L41-L53

You can see the list in our docs here:https://coder.com/docs/admin/templates/extending-templates/parameters#available-form-input-types

can you talk about back compatibility

All previous parameters that were valid, are still valid. This change adds the validation case formulti-select.

why you're not making this "type" field an enum (in the database and in the proto)

Since we source this value from terraform (tfstate), and the terraform validates it. I do not see why we need to have additional strictness incoder/coder. If we were to change the terraform to add, remove, or edit a form type, then previous versions of coder would break on the new terraform provider. As the old enum would be stale.

So I prefer not to enforce an enum, and allow some version dsync between the provider & coder.

Solving that version desync is not something I want to tackle right now. We allow it today.

Also, I don't understand how form_type relates to#17892 which is about deleting workspaces.

multi-select has different validation then is currently supported. This is what a multi-select looks like. Before this PR, alllist(string) validation assumed the string literal value["red","blue"] would exist in the options.

Now if the form type ismulti-select, we know the string literal"red" and"blue" have to each exist in the options.

data"coder_parameter""color" {name="color"type="list(string)"form_type="multi-select"default=`["red","blue"]`option {name="Red"value="red"  }option {name="Blue"value="blue"  }option {name="Green"value="green"  }}

It affects more than deleting, but I hit this because of dynamic parameters. Dynamic parameters skip thecoder/coder validation of their parameters atm. We defer to the terraform to validate.

The deleting bug was triggered if you start with dynamic parameters, and switch back to the classic parameter flow (it's opt in, opt out with the experiment enabled). Switching back had the new multi-select params, without the correct validation.

If we were to change the terraform to add, remove, or edit a form type, then previous versions of coder would break on the new terraform provider. As the old enum would be stale.

So I prefer not to enforce an enum, and allow some version dsync between the provider & coder.

Solving that version desync is not something I want to tackle right now. We allow it today.

This reasoning doesn't make sense to me. If we add a new form type to the Coder Terraform provider, and a template author uses it in a template with an old version of Coderd that doesn't support that new form type,we should not allow that template to be successfully imported. Otherwise, how could we possibly do the right thing when it comes time to actually render and validate the form?

The bug you are hitting withmulti-select is a direct example of this problem: the provider allows a value that a back-level Coderd does not understand and will incorrectly validate.

This is exactly the kind of thing that using API versions on the provisionerd protocol is designed to handle. Ifmulti-select was first supported in v1.6 of the protocol, and it turns out your Coderd only supports v1.5, then you have some indication that it needs to be handled, either by rejectingmulti-selects, or outright refusing to connect to Coderd at all (it would be very strange and rare for provisionerd to be at a higher version than coderd, so erroring out entirely is reasonable IMO).

The deleting bug was triggered if you start with dynamic parameters, and switch back to the classic parameter flow (it's opt in, opt out with the experiment enabled). Switching back had the new multi-select params, without the correct validation.

I'm concerned about this ability to opt in to dynamic parameters and then opt back outwith the same template version. As we add new capabilities to dynamic parameters are we really signing ourselves up to maintain absolute parity via the classic parameter flow?

Based on@spikecurtis's suggestions, I will make this an enum. I am not going to add backwards support for mulit-select, so if no form value comes in, I will not let it pass themulti-select validation.

This strictness will be intentional to support the new features.