Addendum: import/read does not set use_latest_adapter for bigquery_v1 connections — causes false 'Adapter version cannot be changed' errors and compounds timeout_seconds issue.
When importing a BigQuery v1 global connection (either via CLI terraform import or config-driven import {}), the provider's read/import path populates adapter_version = "bigquery_v1" but does not set bigquery.use_latest_adapter in state. This means state has use_latest_adapter = null while the connection is v1. If the config has use_latest_adapter = true, the provider's ModifyPlan guard treats this as a user-requested adapter change and errors with "Adapter version cannot be changed". If the config omits the flag, the plan treats the resource as v0, injects the v0-only default timeout_seconds = 300 into the plan, and the Update path sends it to the API, which rejects it for BigqueryConnectionV1.
Proposed remediation steps to include in the same issue:
-
In readGeneric (pkg/framework/objects/global_connection/common.go), when reading a BigQuery connection, derive and set state.BigQueryConfig.UseLatestAdapter based on the adapter_version returned by the API (e.g., true if adapter_version starts with "bigquery_v1" or equals the latest adapter). This allows imported v1 connections to round-trip and avoids the ModifyPlan false positive.
-
In the Update path (pkg/framework/objects/global_connection/resource.go), guard sending TimeoutSeconds to the API: only include warehouseConfigChanges.TimeoutSeconds when the plan indicates the legacy adapter (use_latest_adapter == false). The Create path already does adapter-aware handling; mirror that behavior in Update.
-
Add regression tests for:
- Importing a bigquery_v1 connection and then running a no-op plan/apply (should be no adapter-change errors).
- Updating a bigquery_v1 connection with no timeout_seconds set should NOT PATCH
timeout_seconds.
Rationale: these two changes together ensure imported v1 connections behave correctly in Terraform, and prevent the provider from sending v0-only fields to v1 API objects. They resolve both the immediate failure mode and prevent future surprises for other users using import blocks.
Addendum: import/read does not set
use_latest_adapterfor bigquery_v1 connections — causes false 'Adapter version cannot be changed' errors and compounds timeout_seconds issue.When importing a BigQuery v1 global connection (either via CLI
terraform importor config-drivenimport {}), the provider's read/import path populates adapter_version = "bigquery_v1" but does not setbigquery.use_latest_adapterin state. This means state hasuse_latest_adapter = nullwhile the connection is v1. If the config hasuse_latest_adapter = true, the provider's ModifyPlan guard treats this as a user-requested adapter change and errors with "Adapter version cannot be changed". If the config omits the flag, the plan treats the resource as v0, injects the v0-only defaulttimeout_seconds = 300into the plan, and the Update path sends it to the API, which rejects it for BigqueryConnectionV1.Proposed remediation steps to include in the same issue:
In readGeneric (pkg/framework/objects/global_connection/common.go), when reading a BigQuery connection, derive and set
state.BigQueryConfig.UseLatestAdapterbased on the adapter_version returned by the API (e.g., true if adapter_version starts with "bigquery_v1" or equals the latest adapter). This allows imported v1 connections to round-trip and avoids the ModifyPlan false positive.In the Update path (pkg/framework/objects/global_connection/resource.go), guard sending
TimeoutSecondsto the API: only includewarehouseConfigChanges.TimeoutSecondswhen the plan indicates the legacy adapter (use_latest_adapter == false). The Create path already does adapter-aware handling; mirror that behavior in Update.Add regression tests for:
timeout_seconds.Rationale: these two changes together ensure imported v1 connections behave correctly in Terraform, and prevent the provider from sending v0-only fields to v1 API objects. They resolve both the immediate failure mode and prevent future surprises for other users using import blocks.