Skip to content

fix: mark invalid UUIDs as known #148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 28, 2024
Merged

fix: mark invalid UUIDs as known #148

merged 2 commits into from
Nov 28, 2024

Conversation

ethanndickson
Copy link
Member

@ethanndickson ethanndickson commented Nov 27, 2024

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.

func (t durationType) ValueFromString(_ context.Context, in types.String) (basetypes.StringValuable, diag.Diagnostics) {
       [...]
	valueString := in.ValueString()
	if _, err := time.ParseDuration(valueString); err != nil {
		return DurationUnknown(), diags // Must not return validation errors
	}
       [...]
}

Meanwhile, this function is called during validate/plan/apply:

func (v Duration) ValidateAttribute(ctx context.Context, req xattr.ValidateAttributeRequest, resp *xattr.ValidateAttributeResponse) {
	if v.IsNull() || v.IsUnknown() {
		return
	}
}

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 in terraform-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 from ValueFromString.

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.

Copy link
Member Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@ethanndickson ethanndickson marked this pull request as ready for review November 27, 2024 03:10
@ethanndickson ethanndickson merged commit f7eec90 into main Nov 28, 2024
14 checks passed
@ethanndickson ethanndickson deleted the ethan/uuid-fix branch November 28, 2024 05:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants