Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When I first implemented the UUID Terraform type, I followed the example from
terraform-provider-aws
for durations: Source. This example doesn't quite make sense, or at the least isn't applicable to our use-case, and since it was used as a base for our custom data type, resulted in UUIDs not being validated when written as strings in a configuration.i.e. This function is called by the plugin SDK, when reading the config.
Meanwhile, this function is called during
validate
/plan
/apply:This means if the duration couldn't be parsed, the value becomes unknown, and then is never validated, and so the provider just sees an Unknown value instead of an error diagnostic.
It's worth noting that you cannot remove the
IsUnknown
check from a validate function, as Terraform purposefully calls validate functions with unknown values when the attribute is set using a variable. The idea being to validate a config before and after any variables are populated. Therefore the only solution here is to return a known, valid value, if the UUID couldn't be parsed, as to let the validator handle it.A similar data type is implemented in such a way that meets our use case for
arn
interraform-provider-aws
, which has been used as a guide for this fix: Source. In this provider, if an ARN can't be parsed, a valid & known value is returned fromValueFromString
.More importantly, I made the mistake of not testing the UUID type failing to parse in the context of a resource / data source. I only wrote internal unit tests for the type. This PR adds a test that ensures an error diagnostic is returned if an invalid UUID is provided to a resource/data-source UUID attribute, which tells us the problem is fixed.