[Bug]: Issues with IDs on 32-bit system/binaries

[apricote]

Problem

When using the terraform provider you might see an error message like the following:

╷
│ Error: json: cannot unmarshal number 504538401287250 into Go struct field Action.action.id of type int
│ 
│   with hcloud_network_subnet.subnet,
│   on main.tf line 23, in resource "hcloud_network_subnet" "subnet":
│   23: resource "hcloud_network_subnet" "subnet" {
│ 

This happens, because the default int type that Terraform uses is not large enough to fit the IDs the Hetzner Cloud API returns when the binary is compiled for 32bit. This can either be the Terraform binary, or the provider binary.

You can find out if you are using the 32bit Terraform binary by running terraform version. This will show the architecture that terraform was compiled for.

Workarounds

If you are running a 64 bit Operating System, you can easily switch to Terraform compiled for 64 bits.

If you are running a 32 bit Operation System, there is no workaround currently available.

Background

Hetzner Cloud announced that the API will return IDs above the 32-bit limit on 15 May 2023, with the new IDs being returned starting 1 September 2023.

This was an issue for all users of hcloud-go, as we were using the Go int type for all IDs. On 64bit systems (most today) thats not an issue, because internally Go uses int64 on those systems. But on 32 bit systems it is a large issue as Go uses int32 internally.

To avoid the issue for users, we released hcloud-go v2 that switched to int64 ID fields everywhere: hetznercloud/hcloud-go#263

Unfortunately, it was not possible to upgrade this dependency in the Terraform provider. We were using the hashicorp/terraform-plugin-sdk/v2 library to implement our provider. This library does not support int64 attributes, it only supports int. Another downside of this library is that it requires constant type assertions from any to the expected type. If the type assertion was using the wrong type, this would crash the provider. It was basically impossible to switch to hcloud-go v2 in this situation, as you could never be sure if the value you were trying to assert was coming from terraform (requiring int) or from hcloud-go (requiring int64). Additionally, if we would use IDs >32bits for resources, this would fail in any way, as Terraform internally would need to save the int but it could not.

The way out was to migrate to hashicorp/terraform-plugin-framework, which was the new kid on the block and which actually supports int64 properly. It also does not require type asserts in most cases, helping us build a more resilient provider.

Unfortunately it changed a lot of things, and migrating resources from SDK v2 to Plugin Framework can only be done with great care to avoid introducing new bugs and incompatibilities.

Because of this, the migration is going slower than expected. Only once we have fully migrated to the Plugin Framework can we upgrade to hcloud-go v2 and fix the issues on 32 bit installations.

You can find the current progress for the Plugin Framework migration in #752.