We chatted about this during the Weekly meeting today (@spikecurtis @mafredri).

Some time ago we implemented #6362 to ensure the order of parameters in the UI based on a single main.tf file. With multiple .tf files and modules, ordering might be fuzzy - sort by filenames, then parse HCL files to check the real order. It means that users won't be able to really control the ordering.

This issue recommends adding another numeric property to coder_parameter - order/priority/weight/index so that Coder can determine the ordering of parameters instead of involving the HCL parser.

data "coder_parameter" "docker_image_name" {
  name        = "Docker Image"
  mutable     = true
  type        = "string"
  description = "Docker image for the development container"
  default     = "ghcr.io/harrison-ai/coder-dev:base"
  priority     = 100
}

BTW it might be tricky to implement it in a backward compatible way. On the other hand, if the order of fields changes after Coder deployment, template admins can easily adjust it later by pushing a template update.

@bpmct Let me know what is the preferred way:

1. Keep the HCL parser to determine ordering whenever it is possible.
2. Change it to use the priority field, and sort parameters based on field values.

Nice issue!

Let's call it order instead of priority and reverse the behavior. order = 1 should come before order = 2, like CSS. This is a pattern I've seen more commonly.

Does this mean that the ordering of agent metadata and resource metadata are non-deterministic too? If so, would you be able to add a follow-up issue for this?

Also, if the order property is not present, can we attempt to use the HCL parser? Are there anticipated risks/debt with this?

I know it is imperfect but better than nothing / random results.

Let's call it order instead of priority and reverse the behavior. order = 1 should come before order = 2, like CSS. This is a pattern I've seen more commonly.

👍 It's a matter of refactoring, but sure.

Does this mean that the ordering of agent metadata and resource metadata are non-deterministic too? If so, would you be able to add a follow-up issue for this?

Terraform always return them sorted in alphanum. order. Parameters are different as they are retrieved directly from the database, and that may cause an issue. It is not a problem of Terraform, but rather a specific PostgreSQL configuration.

Also, if the order property is not present, can we attempt to use the HCL parser?

If we merge the "order" property, Coder will not be able to determine whether parameters are just using order = 0, or not using order at all. In that case, Coder will just sort parameters based on their names consistently, so no randomness.
Unfortunately, the HCL parser will not help here much and I would not like to deal with extra logic to check if the "order" property exists for at least one parameter.

Are there anticipated risks/debt with this?

Once we merge changes for Coder, UI will display existing parameters sorted by names. Template admins will have to fix this behavior by adding order = Z properties. Fortunately, we will not change the parameter handling logic or lose a field.

Due to the non-deterministic behavior of PostgreSQL, it will not be possible to fix it on the migration level.

Gotcha. It all makes sense, thanks.