0.12.24 panic: runtime error: index out of range

[arcotek-ltd]

Terraform Version

Terraform v0.12.24
+ provider.azuread v0.8.0
+ provider.azurerm v2.6.0

Terraform Configuration Files

<product>.tfvars.json:

"automation_account_data" : {
    "0" : [
      {
        "sku_name" : "Basic",
        "custom_tags" : {
          "purpose" : "AAD user creation",
          "createdBy" : "John Smith"
        },
        "modules" : [
          {
           "name" : "Az.Accounts",
           "uri" : "https://psg-prod-eastus.azureedge.net/packages/az.accounts.1.7.5.nupkg"
          },
          {
            "name" : "Az.Resources",
            "uri" : "https://psg-prod-eastus.azureedge.net/packages/az.resources.1.13.0.nupkg"
          },
          {
            "name" : "Az.Automation",
            "uri" : "https://psg-prod-eastus.azureedge.net/packages/az.automation.1.3.6.nupkg"
          }
        ],

Debug Output

Crash Output

crash.log

Expected Behavior

Deploy modules to Azure automation account.

Actual Behavior

Crash.

Steps to Reproduce

terraform plan.
There is a lot more to this deployment, that I cannot share publically, however, I'm happy to share with a Hashicorp dev.

If I empty out the modules array (modules : []) in <product>.tfvars.json, then plan works, however, this will remove installed PowerShell modules.

The TF module that processes the modules: [] section is azurerm_automation_modules which was working fine. I had a bug in my code for another TF module that creates storage account containers:

locals {
  resource_data = flatten([
    for product_key, product in var.storage_account_data : [
      for resource_key, resource in product : [
        for container_key, container in resource.containers : {
          name                  = container.name
          container_access_type = container.container_access_type
          storage_account_name  = var.storage_account_object.object["${product_key}.${resource_key}"].name
          id                    = "${product_key}.${resource_key}.${container_key}"
        }
      ]
    ]
  ])
}

I added container_key to the for loop and the id attribute which is when I started getting the crash, however backing out the change doesn't stop the crash.

I've deleted .terraform directory several times.

I've tried with 0.12.23 and 0.12.24.

Additional Context

References

[danieldreier]

Hi @arcotek-ltd! Thanks for reporting this. This sure looks like a valid issue. The challenge here is that it doesn't look like an easy one to reproduce. It looks to me like this is a multi-step reproduction, where we first need get state into the error condition.

My next step, to get this to an engineer, is that I need to reproduce it on our end.

To do that, I have to be able to run this and run it on my workstation without inventing any details in order to be confident we're seeing the same behavior. As-is, I don't have a very clearreproduction case, and so I'm stuck. I also wanted to clarify two things. First, are you running this on Windows? It looked like it from your crash log. Second, are you using azure for state storage?

What would be most helpful for me is if you can restate your reproduction case such that I can copy-paste it and run it locally. Ideally, this would use the null resource provider rather than a real provider in order to minimize external dependencies. In this case, it looks like the azurerm state backend is needed and I'm happy to use our azure test env for that.

Is that reproduction case something you can help with?

[arcotek-ltd]

Hi @danieldreier,
Thanks for picking this up.
Yes, I am running this on Windows.
Yes, I am using Azure for backend state.

Now the hard bit, I totally understand you need to reproduce this, however, I'm not sure how I can use the null resource to simulate this. It would be much easier for me if I gave you access to my repos or a zip file. Would this be possible?

Thanks.

[danieldreier]

We can use some kind of azure resources if null resources are prohibitive. I'm flexible there. My main goal is to get a very simple to run reproduction case, listed step by step. I'm trying to triage issues into a state where they are ready to go for an engineer to pick up and work without a lot of figuring out of context.

If your codebase pretty much plugs in some azure credentials, and you can tell me what to run in what order, then sharing a zip or a codebase might be sufficient. Most infrastructure code isn't that clean and simple, so if we're going to build a large infrastructure that might become prohibitive.

[arcotek-ltd]

It only deploys a storage account and automation account, but there are countless files for the resources and the modules.
I could zip up the staging directory, including .terraform and all you'd have to do is change the service principal credentials in the local terraform.tfstate for your backend and Azure subscription.

That will give you all the files and all you should have to do is run terraform plan to reproduce the error.

How do I share the zip file with just you?

Thanks

[danieldreier]

@arcotek-ltd I appreciate your willingness to share all that stuff, but a reproduction case involving countless files for resources is just too much context to dig through. We have to narrow this down further into a smaller reproduction case.

Are you seeing this with every run now? Are you able to consistently reproduce this given your current state and code?

[danieldreier]

This looks an awful lot like #23677. Both are running in Azure DevOps and produce the same error from pkg/mod/github.com/hashicorp/hcl/[email protected]/json/peeker.go:20

github.com/hashicorp/hcl/v2/json.(*peeker).Read(...)
	/opt/teamcity-agent/work/9e329aa031982669/pkg/mod/github.com/hashicorp/hcl/[email protected]/json/peeker.go:20

[apparentlymart]

Terraform v0.13 includes a fix to the HCL JSON parser where it was panicking on certain types of syntax error. I'm not certain that the error we see here is the same bug that hashicorp/hcl#358 addressed, but I think it'd be good to re-test this on v0.13.0 once it's released, or (if you can reproduce it with only terraform plan, to avoid making changes to state) with the current v0.13.0-beta2 release.

The fact that the crash is coming from the HCL JSON parser means that this is very likely to be related to something in a .tf.json or .tfvars.json file. The original report shows a <product>.tfvars.json, and the snippet as quoted is invalid (it's missing some closing } and ]), so if that snippet is literally what is in the file then it seems plausible that the syntax error is what's causing the crash, and that hashicorp/hcl#358 would've replaced that with a proper syntax error message.

[mildwonkey]

I am going to close this issue due to inactivity. If you are still experiencing this issue in terraform v0.13, please open a new issue and fill out the issue template so we can take another look.

If you have a question, I recommend the the community forum, where there are far more people available to help.

Thanks!

[ghost]

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.