Initial creation of remote terraform state file blank causing error in TF 0.13

[mjsoh25]

Terraform Version

Terraform v0.13.5

Terraform Configuration Files

data "terraform_remote_state" "purpose_main" {
      backend = "azurerm"
      config = {
        storage_account_name  = "<redacted>"
        container_name        = "<redacted>"
        key                   = "terraform.tfstate"
        access_key            = "<redacted>"
      }
    }

Expected Behavior

A successful Terraform plan

Actual Behavior

Error: Unable to find remote state

  on backend.config.tf line 32, in data "terraform_remote_state" "purpose_main":
  32:     data "terraform_remote_state" "purpose_main" {

No stored state was found for the given workspace in the given backend.

The state file exists however its an empty file causing the terraform_remote_state resource to think that the remote state file doesn't exist.

Steps to Reproduce

Please list the full steps required to reproduce the issue, for example:

1. terraform init -reconfigure -verify-plugins=true
2. terraform plan

Additional Context

When using Terraform 0.12.23

1. terraform init -reconfigure -verify-plugins=true
2. terraform plan

Using Terraform 0.12.23, terraform plan is successful with the same configuration. The only difference is the terraform version. The remote state file using Terraform 0.12.23 shows

{
  "version": 4,
  "terraform_version": "0.12.23",
  "serial": 13,
  "lineage": "ba0524cf-787b-d551-60a6-5b6ad72bce3d",
  "outputs": {},
  "resources": []
}

References

[danieldreier]

@mjsoh25 I'm not clear here, is this an issue you are only seeing with the azurerm state backend, or broadly across all state backends? I'm trying to understand in order to route this work, because the AzureRM state backend isn't maintained by the core team but we can investigate if you're seeing a general issue across all state backends

[mjsoh25]

I have only tested it with the azurerm state backend. If this is the wrong place to post this issue than I apologize in advance.

[danieldreier]

No worries! This looks to me like either a configuration/setup issue or an issue specific to the AzureRM state backend, so I'm going to label it as an AzureRM state backend issue and perhaps those engineers will be able to help.

We use GitHub issues for tracking bugs and enhancements, rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready to help. The GitHub issues here are monitored only by our few core maintainers.

Based on the information you've provided, it looks like this doesn't represent a specific bug or feature request, and so I'm going to assume it's not a core issue until we have further information. The Terraform Providers community forum is another good place to ask questions if you're still troubleshooting.

If you're confident that this is a bug in core, the next step would be to try and reproduce it with other backends, and confirm that this is a general bug across backends rather than one in AzureRM.

[jbardin]

Hi,

This is the expected result of attempting to decode an empty state file, and should happen with any backend (and can be confirmed using the local remote state backend). The state is not represented by the file, but rather by the state structures it contains, therefore an empty file contains no remote state. Data sources are also generally expected to return an error when a singular resource they represent does not exist, so the terraform_remote_state resource is behaving accordingly here.

This was likely fallout from being able to better handle complex data types in remote state objects, but I'm not sure exactly where the change was made. I do not think it was intended previously that an empty file would be a valid remote state either. Is there a particular workflow you have where the remote state cannot be initialized beforehand?

Thanks!

[mjsoh25]

This error occurs when we are attempting to create the infrastructure for the first time. In Terraform 0.12 the remote state file gets created and initializes perfectly fine so the terraform_remote_state resource works as intended. When attempting to create a new environment with the same Terraform code using Terraform version 0.13, the remote state file gets created but its not initialized (blank file).

Something changed in TF version 0.13 that's causing the remote state file to not initialize.

[mjsoh25]

@jbardin When attempting to run a terraform plan in Terraform 0.13/0.14 for the first time, is the statefile supposed to be completely blank upon creation? In terraform 0.12 the statefile gets created with the following

{
  "version": 4,
  "terraform_version": "0.12.29",
  "serial": 0,
  "lineage": "",
  "outputs": {},
  "resources": []
}

[jbardin]

@mjsoh25, terraform plan should not create nor write to an existing state file. The terraform_remote_state data source is read-only and should never create or write to a state file.

[mjsoh25]

@jbardin I understand that the terraform_remote_state data source is read only. I am just confused why in Terraform 0.13/0.14, when the statefile first gets created initially, the statefile is completely blank whereas in Terraform 0.12 it is not.

[jbardin]

@mjsoh25, The state should initially be written by terraform apply. Seeing how the state you are showing has a "serial" value of 13, my guess is that you have already created and destroyed resources within this state, which is why it currently exists. After re-testing with 0.12, I'm not seeing any way in which the state could be created from an init with no other inputs. Regardless of how it was created in your particular case, the current behavior should be that no initial state is saved until apply is executed.

This does not appear to be a bug in Terraform, so I'm going to close this out for now. We use GitHub issues for tracking bugs and enhancements, rather than for questions. While we can sometimes help with certain simple problems here, it's better to use the community forum where there are more people ready 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.