Framework v1.3.2 pathSteps in AddAttributeError() not producing the results I expect

Terraform Providers Plugin Development
1

A data source within my provider has a configuration which looks like this:

1  data "path_example" "e" {
2    number_list = [
3      {
4        number = "3"
5        must_be_even = true
6      }
7    ]
8  }

The data source’s ValidateConfig() method rejects this configuration because 3 is an odd number and must_be_even is true. So far, so good.

I can point the user-facing error to the problem using AddAttributeError()'s path.Path argument, but not with as much specificity as I’d expected.

Using path.Root("number_list").AtListIndex(i) does what I expect: It cites line 3 (the beginning of the nested list item at index i) as the problem spot:

╷
│ Error: invalid attribute combination
│
│   with data.path_example.e,
│   on main.tf line 3, in data "path_example" "e":
│    3:     {  
│    4:       number = "3"
│    5:       must_be_even = true
│    6:     }  
│
│ number must be even when must_be_even is true
╵

But I’d prefer it point at the number attribute on line 4. Using path.Root("number_list").AtListIndex(i).AtName("number") does not do what I expect.

Instead of pointing at the number attribute within the nested object at index i, it points to the top of the resource block:

╷                               
│ Error: invalid attribute combination
│                               
│   with data.path_example.e,   
│   on main.tf line 1, in data "path_example" "e":
│    1: data "path_example" "e" {
│                               
│ number must be even when must_be_even is true
╵

Is this expected behavior? Perhaps I’m not expressing the path correctly?

Thanks!

There’s a skeleton provider which demonstrates the situation here.

2

Hi @hQnVyLRx :wave:

That behavior does not sound correct, but we’ll need to figure out whether it is an issue on the provider side of the protocol (e.g. a bug in terraform-plugin-framework or terraform-plugin-go) or in the human readable output of Terraform core after it receives the provider path information. Enabling trace logging (e.g. TF_LOG=trace) should include a ValidateDataSourceConfig RPC response message with the error diagnostic you generated. I believe that log message should include path information if the provider included it with the diagnostic. If the path looks like you would expect there, I would raise an issue in the Terraform core issue tracker.

1 Like
3

Thank you, @bflad.

I didn’t find ValidateDataSourceConfig in the trace output, but this line correctly expresses the intended path:

2023-07-07T14:03:08.141-0400 [ERROR] provider.terraform-provider-path: Response contains error diagnostic: @module=sdk.proto @caller=/Users/cmarget/golang/pkg/mod/github.com/hashicorp/terraform-plugin-go@v0.17.0/tfprotov6/internal/diag/diagnostics.go:58 diagnostic_summary="invalid attribute combination" diagnostic_detail="number must be even when must_be_even is true" diagnostic_severity=ERROR tf_provider_addr=registry.terraform.io/chrismarget/path tf_req_id=9d55996c-0dcb-69be-6e11-baa2ddd94e74 diagnostic_attribute=AttributeName("number_list").ElementKeyInt(0).AttributeName("number") tf_data_source_type=path_example tf_proto_version=6.3 tf_rpc=ValidateDataResourceConfig timestamp=2023-07-07T14:03:08.141-0400

Should we interpret it to mean that the intended path was communicated to Terraform core?

The whole trace log is here.

Do you happen to know what term should I use to refer to this feature where config validation errors cite relevant sections of the .tf config files? I figure the citation engine has a name…

4

I personally would interpret AttributeName("number_list").ElementKeyInt(0).AttributeName("number") there to be correct given the prior information in this post, but you would know best based on the configuration you’re giving it (e.g. the diagnostic is intended to be reported is actually on the number_list attribute that is a list, at the first element index that is an object, at the number attribute).

The plan output handling is done by the “plan renderer” and this appears to be an issue where the renderer is not getting (or properly using) the associated configuration source information given by a provider diagnostic’s “attribute path” data. I don’t think it has any special name.

1 Like
5

Right on. Thank you, Brian.