fix incorrect field reference

[Integralist]

While testing out the documentation for creating a default value my LSP informed me that there was no field AttributePlan and upon checking the relevant type I found there was a PlanValue which seems to be what should be referenced in the example code.

[hashicorp-cla]

All committers have signed the CLA.

[Integralist]

I should add I was confused by the above logic for returning early if 'unknown' as the attribute has to be marked as both computed and optional so that the user can configure a value while the provider can set a value if none is provided by the user, and so the PlanValue will naturally be 'unknown' or 'known'.

If it's known (e.g. the user provided a value), then of course return early and don't set a value. But if the value is 'unknown' (e.g. the user didn't provide a value), then returning early here will mean you have to programmatically check in the resource's Create method and set the default there (making this whole implementation sort of pointless from a 'I need to set a default' perspective).

So for myself I modified the value like so:
Integralist/terraform-provider-fastly-framework@35d10ec#diff-5dba0fe3376c40571fbc1323ead12e5626199bed5a36e4c9f217e3d9aced8cabR36-R37

[bflad]

Unknown values can come from two main sources:

• The framework automatically marking Computed attributes with a null configuration value during planning to prevent a class of inconsistent result after apply Terraform errors
• Other data source and resource attribute values which are only known after apply, e.g.

resource "examplecloud_thing" "example" {}

resource "examplecloud_widget" "example" {
  thing_id = examplecloud_thing.example.id # incoming unknown value during planning
}

It can be incorrect in the latter scenario to unilaterally change the planned value to a default value when the planned value is unknown, since it may be an artifact of the way the configuration is written. Terraform would raise an error if the plan was set to the default and the incoming configuration value was different.

This code example might be best served with an update to check !req.ConfigValue.IsNull() for clarity (and to allow prior plan modification to set a null plan value successfully), but it might be best to create a separate issue/PR to discuss this type of example change further.

[bflad]

Thank for you this code example fix, @Integralist 🚀

[bflad]

Unknown values can come from two main sources:

• The framework automatically marking Computed attributes with a null configuration value during planning to prevent a class of inconsistent result after apply Terraform errors
• Other data source and resource attribute values which are only known after apply, e.g.

resource "examplecloud_thing" "example" {}

resource "examplecloud_widget" "example" {
  thing_id = examplecloud_thing.example.id # incoming unknown value during planning
}

It can be incorrect in the latter scenario to unilaterally change the planned value to a default value when the planned value is unknown, since it may be an artifact of the way the configuration is written. Terraform would raise an error if the plan was set to the default and the incoming configuration value was different.

This code example might be best served with an update to check !req.ConfigValue.IsNull() for clarity (and to allow prior plan modification to set a null plan value successfully), but it might be best to create a separate issue/PR to discuss this type of example change further.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.