-
Notifications
You must be signed in to change notification settings - Fork 93
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
Comments
It turns out that with the following change, the |
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. |
@magodo The fix has been merged to main and will be released with the upcoming In the meantime, you can test your changes off the latest changes in go get -u github.com/hashicorp/terraform-plugin-framework@main |
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. |
Module version
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 thebody
, which was a string represents the configurable attribute of this restful resource. Meanwhile it exports an attribute namedoutput
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
andoutput
from string to dynamic type. To support these well, the type consistency needs to take into consideration for sure. For thebody
, 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 astuple
, and json object asobject
. The problem of doing this is that when something changed in the remote end (comparing to the state), e.g. size change for atuple
, or new attribute added for anobject
, we will violate the type consistency issue, results into error like below: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
The text was updated successfully, but these errors were encountered: