Google BigQuery table are being force replaced , even when there is no change in the schema structures. #9472
Comments
|
@Sophyiya Can you please attach the plan output to get an idea about what's causing the resource to be recreated ? |
|
terraform_plan_forces_replacement.txt @venkykuberan I have uploaded the terraform plan which forces the replacement of tables. The plan shows that the Objects have changed outside of Terraform, but that is not the case. |
|
It looks like case-sensitive diff causing the resource to be recreated. I will change this issue as bug and we will work on the fix. |
|
@venkykuberan Thanks for the update. So the reason for force replacement is "type" and "mode" for the columns were case sensitive. Did I get the root cause correctly? |
|
@Sophyiya yes, that's what is causing the recreation. |
|
I don't know if they're case sensitive for BigQuery table schemas; from the terraform side, we have considered those fields to be case-sensitive, which is what triggered recreation. |
|
@melinath Thanks for confirming. |
|
Verified I can reproduce this locally. BigQuery table accepts lowercase mode & type and then uppercases them in the returned value, causing a permadiff. |
BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved hashicorp/terraform-provider-google#9472
* Ignored case changes in bigquery table schema mode/type BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved hashicorp/terraform-provider-google#9472 * Handle invalid input from users without a panic
* Ignored case changes in bigquery table schema mode/type BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved hashicorp#9472 * Handle invalid input from users without a panic Signed-off-by: Modular Magician <[email protected]>
* Ignored case changes in bigquery table schema mode/type BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved hashicorp/terraform-provider-google#9472 * Handle invalid input from users without a panic Signed-off-by: Modular Magician <[email protected]>
* Ignored case changes in bigquery table schema mode/type BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved #9472 * Handle invalid input from users without a panic Signed-off-by: Modular Magician <[email protected]>
* Ignored case changes in bigquery table schema mode/type BigQuery table schema normalizes the mode and type to uppercase, which causes a permadiff for the end user if they set it in lowercase. Also removed tests for setting type to nil, because a field type being nil is invalid. Resolved hashicorp/terraform-provider-google#9472 * Handle invalid input from users without a panic Signed-off-by: Modular Magician <[email protected]>
|
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. |
Noticed similar kind of issues about force replacement were already discussed at #8710 and #8803, also fix was released.But when we were trying to provision the bigquery table resource with google provider V3.74.0, during the consecutive Terraform apply,the tables are being force replaced(detroyed and recreated)even though there is no change in the schema structure
Interestingly, when we tried Terraform apply using one of the older google provider V3.55.0 and could see there was no force replacements.
Is this the expected behavior? And how to avoid the force replacements for bigquery tables in V3.74.0?
The text was updated successfully, but these errors were encountered: