Terraform: panic: strconv.Atoi: parsing "2955597155": value out of range

[rcaunt]

Terraform Version

Terraform v0.11.3
Terraform AWS Provider v1.10.0

Terraform Configuration Files

We're sourcing subnet IDs using the following manner:

data "aws_vpc" "main" {
  filter {
    name   = "tag:Environment"
    values = ["${var.environment}"]
  }
}

data "aws_subnet_ids" "private" {
  vpc_id = "${data.aws_vpc.main.id}"
}

data "aws_subnet" "private" {
  count = "${(length(data.aws_subnet_ids.private.ids))/2}"
  filter {
    name   = "tag:Name"
    values = ["${var.environment} - Private ${count.index + 1}"]
  }
}

Debug Output

https://gist.github.com/rcaunt/4fbc9ac7f98950a5328b42cb0005e01f

Crash Output

Not available yet as I am running in a GitLab CI docker.

Expected Behavior

The plan statement should succeed and subnet IDs are returned. This is working in a few AWS environments fine.

Actual Behavior

Terraform crashes

Steps to Reproduce

1. terraform init
2. terraform plan

Additional Context

It seems that the value it can't parse is associated with a subnet, when looking in the state file I can see the following for the network ACL:

"aws_network_acl.main": {
                    "type": "aws_network_acl",
                    "depends_on": [
                        "aws_subnet.private.*",
                        "aws_subnet.public.*",
                        "aws_vpc.main"
                    ],
                    "primary": {
                        "id": "acl-323fe05a",
                        "attributes": {
                            "egress.#": "2",
                            "egress.1401401844.action": "allow",
                            "egress.1401401844.cidr_block": "0.0.0.0/0",
                            "egress.1401401844.from_port": "0",
                            "egress.1401401844.icmp_code": "0",
                            "egress.1401401844.icmp_type": "0",
                            "egress.1401401844.ipv6_cidr_block": "",
                            "egress.1401401844.protocol": "-1",
                            "egress.1401401844.rule_no": "100",
                            "egress.1401401844.to_port": "0",
                            "egress.3055423686.action": "allow",
                            "egress.3055423686.cidr_block": "172.30.0.0/16",
                            "egress.3055423686.from_port": "0",
                            "egress.3055423686.icmp_code": "0",
                            "egress.3055423686.icmp_type": "0",
                            "egress.3055423686.ipv6_cidr_block": "",
                            "egress.3055423686.protocol": "-1",
                            "egress.3055423686.rule_no": "200",
                            "egress.3055423686.to_port": "0",
                            "id": "acl-323fe05a",
                            "ingress.#": "3",
                            "ingress.1469908276.action": "allow",
                            "ingress.1469908276.cidr_block": "0.0.0.0/0",
                            "ingress.1469908276.from_port": "1024",
                            "ingress.1469908276.icmp_code": "0",
                            "ingress.1469908276.icmp_type": "0",
                            "ingress.1469908276.ipv6_cidr_block": "",
                            "ingress.1469908276.protocol": "6",
                            "ingress.1469908276.rule_no": "300",
                            "ingress.1469908276.to_port": "65535",
                            "ingress.2964485317.action": "allow",
                            "ingress.2964485317.cidr_block": "10.2.0.0/16",
                            "ingress.2964485317.from_port": "0",
                            "ingress.2964485317.icmp_code": "0",
                            "ingress.2964485317.icmp_type": "0",
                            "ingress.2964485317.ipv6_cidr_block": "",
                            "ingress.2964485317.protocol": "-1",
                            "ingress.2964485317.rule_no": "100",
                            "ingress.2964485317.to_port": "0",
                            "ingress.3055423686.action": "allow",
                            "ingress.3055423686.cidr_block": "172.30.0.0/16",
                            "ingress.3055423686.from_port": "0",
                            "ingress.3055423686.icmp_code": "0",
                            "ingress.3055423686.icmp_type": "0",
                            "ingress.3055423686.ipv6_cidr_block": "",
                            "ingress.3055423686.protocol": "-1",
                            "ingress.3055423686.rule_no": "200",
                            "ingress.3055423686.to_port": "0",
                            "subnet_ids.#": "4",
                            "subnet_ids.1603914870": "subnet-6eed0c14",
                            "subnet_ids.2722804770": "subnet-258abd68",
                            "subnet_ids.2732942929": "subnet-4aef0e30",
                            "subnet_ids.2955597155": "subnet-1276405f",
                            "tags.%": "2",
                            "tags.Environment": "Dev",
                            "tags.Name": "Dev - ACL",
                            "vpc_id": "vpc-a0669cc8"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.aws"
                },

In particular this part:

                            "subnet_ids.#": "4",
                            "subnet_ids.1603914870": "subnet-6eed0c14",
                            "subnet_ids.2722804770": "subnet-258abd68",
                            "subnet_ids.2732942929": "subnet-4aef0e30",
                            "subnet_ids.2955597155": "subnet-1276405f",

[apparentlymart]

Hi @rcaunt! Sorry for this crash.

It looks like this is a disagreement between two different parts of Terraform about what format that number is in. The code that created it treats it as an unsigned integer while the code that is parsing it is treating it as signed.

Am I right in assuming here that you are using a 32-bit build of Terraform? I expect this bug would only occur on 32-bit builds because on 64-bit builds we would generate an unsigned 32-bit integer and then parse a signed 64-bit integer, which would then be in range.

We'll look into this and get the integer types lined up to fix this problem. In the mean time, if you _are_ running a 32-bit build but are on a system where you could run a 64-bit build I think switching to the 64-bit build should allow you to bypass this problem.

[rcaunt]

Hi @apparentlymart as far as I know both versions are 64-bit (terraform and the provider) but will need to confirm, I'll post back once I know. As far as I am aware, we are using 64-bit tooling.

A bit more background, we use a GitLab CI Linux box (AWS EC2) to create our infrastructure. One project has been run prior to this using Linux tooling to create the base VPC infrastructure. In a separate project on the same box we've then run the pipeline to create some additional infrastructure, this is where we've seen the issue.

I think we have some additional projects that reference the same state, albeit in a slightly different way so I'll look to see if they demonstrate the same issue.

[rcaunt]

Had a chance to confirm what versions are i use:

Terraform v0.11.3 32-bit
Terraform AWS v1.10.0 64-bit

So you are correct. I've had the 32-bit version changed to 64-bit as there is no reason for us not to use it.

[apparentlymart]

Thanks for following up, @rcaunt! Hopefully using the 64-bit version addresses this problem for you in the short term.

For the longer term, we're already working on a set of changes to the internals of the configuration language and data structures that uses a different representation of sets that should avoid this problem, and that should be in the next major release and so I think we will hold on this for now and let the work already in progress address it as a side-effect.

[apparentlymart]

Hi again @rcaunt!

I just wanted to note here that the work I mentioned before has completed and is now in master ready to be included in the forthcoming v0.12.0 release. The relevant change for this issue is that Terraform Core now uses arbitrary-precision numbers rather than machine-native integer and float types, and so the native size of integers on the machine is no longer important.

The provider SDK is still using native integers at this time, so numbers passed in to an integer argument for a 32-bit provider build will be detected during that conversion and an error reported. In a subsequent release the provider SDK itself will also use the arbitrary-precision number representation, but we've retained the old approach for the moment so that new provider releases can continue to support Terraform 0.10 and 0.11 during a transition period.

I know you already worked around this by switching to the 64-bit build, so this news won't really affect you directly, but since it's now fixed in master I'm going to close out this issue. Thanks for reporting this!

[hashibot[bot]]

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.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.