Variable validation error message requirements relaxed?

Terraform
1

I’m trying to understand whether the below variable validation {} error message validation is a known and expected behavior.

terraform validate for this var definition:

variable "test" {
  type = number

  validation {
    condition     = var.test > 0
    error_message = "error"
  }
}

This is what I get with TF 0.14:

Validation error message must be at least one full English sentence starting
with an uppercase letter and ending with a period or question mark.

TF 0.15:

│ The validation error message must be at least one full sentence starting with an uppercase letter and ending with
│ a period or question mark.
│
│ Your given message will be included as part of a larger Terraform error message, written as English prose. For
│ broadly-shared modules we suggest using a similar writing style so that the overall result will be consistent.

All the TF version way up to 1.1.9 are consistent in throwing validation error, while TF of any higher version does not output any error :confused: The last TF version I get validation error with is 1.1.9. Other versions (>= 1.2.0) produce no validation error. Is this expected? Has error_message validation rules been relaxed? If yes, where I can find an announcement on this?
Thank you.

2

Hi @yermulnik,

The Terraform v1.2.0 changelog entry includes the following:

  • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)

Although not directly mentioned as part of this terse changelog entry, the linked pull request includes some extra commentary:

As part of this change, we also necessarily remove the heuristic about the error message format. This guidance can be re-added in future as part of a configuration hint system.

Therefore, indeed the rule you are referring to is absent in Terraform v1.2.0 and later. In that and later versions, authors are free to use whatever quality of error message they wish.

This was a pragmatic change because v1.2.0 allowed error_message to be dynamically generated for the first time, whereas previously it was required to be a static string only. With a static string this check was defensible as a given module was either always valid or always invalid, but once the error message became dynamic it became possible for an error message to sometimes be valid and sometimes be invalid depending on the dynamic situation, which is a more challenging situation for module authors to test and feedback suggested that most authors would prefer to dispense with the check than risk having it accidentally triggered in situations they didn’t think to test.

1 Like
3

@apparentlymart Yeah, I found that PR already and the removed code bit on the check for required trailing chars. Thanks for the pointer.

How much is it probable that this can be re-added in future?
Should this guidance («The string must be at least one full sentence, which implies having sentence-ending punctuation») be mentioned in corresponding pages of TF documentation to reflect what devs and engineers are expected to use (and maybe refer condition from older versions of TF to let people know there’s no error message format enforcement since TF 1.2.0)?
I just want to be sure that when I encourage and motivate colleagues to conform with common TF convention on full sentence with a trailing dot in messages (since we have a lot of var validations that were added prior to TF 1.2.0 and now that we also use TF >1.2.0 we continue aligning with common approach) I don’t look like a jerk who’s asking them to conform with the non-existent enforcement/guidance :smiley:

Thanks for your prompt and detailed response, guidance and pointers. As always your input is much appreciated and helpful.

4

Hi @yermulnik,

You are the first person who has asked about the removal of that check, and so it seems that it wasn’t something that most people were relying on, and hence there has been little demand (until now, none at all) for replacing it.

This was an unusual sort of check in Terraform anyway given that it’s primarily a style thing rather than a functionality thing. That sort of concern is typically handled by separate lint tools as that message implies, but the Terraform team at HashiCorp does not maintain any such tools directly. There are some third-party, community-maintained tools for “linting” and other kinds of style enforcement, and so probably the best approach for right now would be to see if any of those offer a comparable rule, and if not then to contribute such a rule to one of them.

5

Hey @apparentlymart
I’m not asking to remove that check. I’m asking for a bit of clarification in the TF docs that before v1.2.0 there was a requirement for a full sentence with a trailing dot, that was relaxed since then while general guidance is to obey the “full sentence with a trailing dot” guidance.
Thanks.