terraform-plugin-sdk
terraform-plugin-sdk copied to clipboard
Value out of range on 32-bit architecture
Essentially a duplicate of https://github.com/hashicorp/terraform-plugin-sdk/issues/469 because I can't reopen. This continues to reoccur in the Google provider from time to time. For reference: https://github.com/hashicorp/terraform-provider-google/issues/15501 https://github.com/hashicorp/terraform-provider-google/issues/13775
SDK version
1.11.0 - v2.24.0 (at least)
Relevant provider source code
Terraform Configuration Files
See linked bugs, though I'm not sure it's reproducible deterministically
Debug Output
Expected Behavior
Actual Behavior
panic: Error reading level state: strconv.ParseInt: parsing "1691737052926": value out of range
goroutine 210 [running]:
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*ResourceData).get(0x1774b9a0, {0x178009a0, 0x1, 0x1}, 0x8)
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource_data.go:553 +0x279
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*ResourceData).State(0x1774b9a0)
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource_data.go:351 +0x3a7
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).ShimInstanceStateFromValue(0x16883b90, {{{0x3dba9a0, 0x1776ffa0}}, {0x31e6fe0, 0x1675a600}})
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:599 +0x1d9
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0x16c496a0, {0x3dba2c0, 0x171a7218}, 0x165c1a40)
github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:587 +0x23f
github.com/hashicorp/terraform-plugin-mux/tf5muxserver.muxServer.ReadResource({0x16c079e0, 0x16c07a20, {0x16cd8260, 0x2, 0x2}, {0x0, 0x0, 0x0}, {0x0, 0x0, ...}, ...}, ...)
github.com/hashicorp/[email protected]/tf5muxserver/mux_server_ReadResource.go:26 +0x151
github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0x1701a3c0, {0x3dba2c0, 0x171a6e58}, 0x16d185d0)
github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:748 +0x4c5
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0x36ceda0, 0x1701a3c0}, {0x3dba2c0, 0x171a6e58}, 0x17755440, 0x0)
github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:349 +0x18a
google.golang.org/grpc.(*Server).processUnaryRPC(0x17010d80, {0x3dbecfc, 0x16f74240}, 0x165200a0, 0x16dfc978, 0x54e6b48, 0x0)
google.golang.org/[email protected]/server.go:1337 +0xed7
Steps to Reproduce
Not entirely sure, we need to get a huge number into a resource in a 32-bit architecture. It seems to come up sometimes, but I'm not sure why exactly
References
https://github.com/hashicorp/terraform-plugin-sdk/issues/469 but I can't reopen it
Hi @slevenick 👋 Thank you for raising this and sorry you folks are running into trouble here. Not suggesting this should be closed, but related issue for tracking: #1215
Unfortunately I need to say upfront that this should not be an issue when resources are migrated to terraform-plugin-framework, since its type system through-and-through supports 64-bit integers, 64-bit floating point numbers, and 512-bit arbitrary precision numbers if really necessary. The internals of this SDK tend to rely on the runtime architecture specific int type, which means it could be awkward to adjust in certain cases, especially if the changes would affect exported functionality.
Ok, good to know that the plugin framework will fix it. We are still a ways away from being able to convert existing resources to the plugin framework, so any workarounds of possible fixes on the SDK would be helpful
This looks like a blocker, is there any workaround? I have Windows 64 bit and I just can't work with terraform.
Upgraded GCP provider and terraform and no success. There's no option to choose how to run Terraform (64 vs 32) so why it is trying to run it be default using x32?
The problematic thing is: "module": "module.gcp_bigquery", "mode": "managed", "type": "google_bigquery_dataset", we have there "creation_time": 1682188988890,
actually, there are much more ints. Also in google_bigquery_table and in google_compute_managed_ssl_certificate - certificate_id.