ExactlyOneOf validator doesn't error plan in some cases

Terraform Providers Plugin Development
1

Hi, I’m using the new terraform-plugin-framework and I’m running into an issue where if I make two inputs mutually exclusive with ExactlyOneOf, but one of them is passed at runtime from another resource block in terraform, it doesn’t error till it gets there during the apply, rather than at the planning stage.

in code, provider:

func (r *twoResource) Schema(_ context.Context, _ resource.SchemaRequest, resp *resource.SchemaResponse) {
    resp.Schema = schema.Schema {
		Attributes: map[string]schema.Attribute {
			"att_one": schema.Int64Attribute {
                Optional: true,
                Validators: []validator.Int64{
                    int64validator.ExactlyOneOf(path.Expressions{
                        path.MatchRoot("att_two"),
                    }...),
                },
            },
			"att_two": schema.Int64Attribute {
                Optional: true,
                Validators: []validator.Int64{
                    int64validator.ExactlyOneOf(path.Expressions{
                        path.MatchRoot("att_one"),
                    }...),
                },
            },
          },
	}
      }

main.tf:

resource "provider_resource1" "example" {
  description  = "This is an integration test"
  name         = "Test"
}

resource "provider_resource2" "example2" {
  att_one = "${provider_resource1.example.id}" // this only breaks during apply, after creating provider_resource1
//  att_one      = 1 //this breaks on plan
  att_two = 2
}

Is this the expected outcome? I can’t see why you’d want that to not be a planning error, even if you don’t know what the value is ahead of time.

2

Hi @fenris1337 :wave:

I believe that this is expected behaviour. At the time of the plan, the value for att_one is unknown, and as a consequence, validation is delayed. It is possible that an unknown value could resolve to being null during apply. For instance, in the case you described, the value of provider_resource1.example.id could resolve to null during apply, and validation would succeed under these circumstances. The delaying of validation until apply is a consequence of provider_resource1.example.id being computed, or possibly computed and optional, which, for cases where the value is computed, means that the value is not known until apply.

3

Hey, thanks for the answer. So it doesn’t seem like there’s anyway to get it to error out on plan in this case? It feels cleaner to me to not half complete my apply and then fail, but I get that’s not exactly viewed as a problem from terraform’s point of view.

4

One possible way to address the issue is for the value of provider_resource1.example.id to be generated at plan time, if possible. This would then expose a known value to resource "provider_resource2" "example2" and the validator would be able to ascertain whether both att_one and att_two were non-null values at plan time.

5

Unfortunately in my case its generated during the apply. I’ll just document it as a potential issue and move on. Thanks for the help!