Skip to content
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

Computed only dynamic typed attribute tolerate type inconsistency #969

Closed
magodo opened this issue Mar 24, 2024 · 4 comments · Fixed by #970
Closed

Computed only dynamic typed attribute tolerate type inconsistency #969

magodo opened this issue Mar 24, 2024 · 4 comments · Fixed by #970
Assignees
Labels
bug Something isn't working
Milestone

Comments

@magodo
Copy link

magodo commented Mar 24, 2024

Module version

v1.7.0

Use-cases

I'm trying to add the new support of dynamic type to the restful provider (a general provider for support restful APIs), in my test branch.

There is a major resource in this provider named restful_resource. The essential attribute is the body, which was a string represents the configurable attribute of this restful resource. Meanwhile it exports an attribute named output that by default holds the whole API model, which is also a string.

What I'm trying to do is to change the types of body and output from string to dynamic type. To support these well, the type consistency needs to take into consideration for sure. For the body, it works well as the types of each attribute is defined by the user's TF config (though there are still works needed for import support, but I leave it as is off topic).

Whilst for output, since it is a comptued only attribute, we don't have the information of type. So in this case, what we can do is to imply the types of a JSON object by default. E.g. assume the json array as tuple, and json object as object. The problem of doing this is that when something changed in the remote end (comparing to the state), e.g. size change for a tuple, or new attribute added for an object, we will violate the type consistency issue, results into error like below:

│ Error: Provider produced inconsistent result after apply

│ When applying changes to examplecloud_thing.example, provider "provider["TYPE"]" produced an unexpected new value: .example_attribute: wrong final value type: tuple required.

│ This is a bug in the provider, which should be reported in the providers own issue tracker.

Attempted Solutions

Proposal

I'm not sure whether it is possible or introduce a side effect, but I'd like there is a way to allow computed only attribute to tolerate the type inconsistency issue above, so that we can manage to change the type of output to dynamic.

Meanwhile, if there is anything I missed during my implementation, it's also appreciated to point out.

References

@magodo magodo added the enhancement New feature or request label Mar 24, 2024
@magodo
Copy link
Author

magodo commented Mar 25, 2024

It turns out that with the following change, the output can support the expected behavior: magodo/terraform-provider-restful@055137e. Whilst I still doubt if this shall be the default behavior.

@austinvalle
Copy link
Member

austinvalle commented Mar 25, 2024

Hey there @magodo 👋🏻 , thanks for reporting this and sorry you're running into trouble here.

This initially looks like a framework bug to me, because the computed dynamic value should be allowed to determine it's own type and value if not already planned.

Digging a little deeper with your example, it looks like the automatic marking of computed values as unknown the framework does seem to be including type information when marking a dynamic value as unknown, which needs to be fixed.

@austinvalle
Copy link
Member

@magodo The fix has been merged to main and will be released with the upcoming terraform-plugin-framework v1.8.0 release.

In the meantime, you can test your changes off the latest changes in main if you'd like:

go get -u github.com/hashicorp/terraform-plugin-framework@main

Copy link

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

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
2 participants