-
Notifications
You must be signed in to change notification settings - Fork 91
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
field producing spurious plan changes with framework but not SDK v2
#628
Comments
Thank you so much for filing this detailed bug report, @asaba-hashi. I'm going to look into this particular case further, hopefully in the context of also implementing #627. |
While trying out #627 logging, it looks like the
Here's the schema from the time I pulled down the code: "operations": schema.StringAttribute{
Description: "Actions that are executed when a corresponding condition is met.",
Required: true,
// PlanModifiers currently tries to diff the json objects and
// ignore formatting changes, but long term should probably
// be a TODO for a more complete schema and encouraging
// jsonencode() usage instead.
PlanModifiers: []planmodifier.String{
jsonIgnoreDiffPlanModifier(),
},
// TODO: similar to above, longer term is to define more of the
// schema for HCL and encourage use of jsonencode()
// Alternative: Look for a JSONString CustomType that comes
// with it's own validation in it's marshalling
Validators: []validator.String{
jsonValidator{},
},
}, I'm suspecting that it may be JSON string normalization that may be causing the issue in this case. The current plan modification workaround you are using is a possible solution for now, however it does not scale. In these cases where possible, it's generally preferable to prevent the state from becoming out of sync with the configuration and therefore the next plan. This also prevents Terraform from potentially being noisy about drift detection. The way you can do this is by adding a similar JSON normalization check to the #70 would be an enhancement so custom types (and/or attribute definitions) can signal semantic equality between two values. In this case, there would be a JSON string custom type (potentially provided by HashiCorp in the future) that would implement the JSON normalization logic. The framework could determine automatically during This would be similar to the very recent |
This should be covered by #737, which will release with v1.3.0 soon. The https://developer.hashicorp.com/terraform/plugin/framework/handling-data/custom-types documentation page releasing with v1.3.0 will be revamped to cover how to set up a custom type with the logic to automatically handle situations like these. 👍 |
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
Relevant provider source code
PR for updating the provider to framework: https://github.com/JupiterOne/terraform-provider-jupiterone/pull/136/files#diff-516571d421fdf72766d23e79357696f48d9949132cfd700d30df5a26fa0dc8aa
These errors are occurred in the tests when moving from SDK v2 to Framework:
Framework:
SDK:
Terraform Configuration Files
This happens as part of the acceptance tests.
Debug Output
https://gist.github.com/asaba-hashi/275dd1d9fc6f774a2ae5629143acde30
Expected Behavior
The tests should have passed because no changes were detected in the plan for just the computed field.
Actual Behavior
The test failed with:
Adding
UseStateForUnknown()
produces the following error:A full workaround can be implemented by providing a
ModifyPlan()
that will run after the field plan modifier:Steps to Reproduce
(*RuleResource) ModifyPlan()
UseStateForUnknown
on theversion
field schemamake test
.References
The text was updated successfully, but these errors were encountered: