### Terraform Version ```shell $ terraform version Terraform v0.15.3 on linux_amd64 ``` WSL2 Ubuntu-20.04 ### Terraform Configuration Files ```terraform terraform { backend "s3" {} } ``` ### Steps to Reproduce On a blank environment (no existing state file in backend)! ```shell $ terraform init -backend-config="bucket=${BUCKETNAME}" \ -backend-config="key=terraform.tfstate" \ -backend=true \ -get=true \ -input=false $ terraform state list ``` ### Expected Behavior it should return nothing and not fail ```shell $ terraform state list $ echo $? 0 ``` ### Actual Behavior ```shell $ terraform state list No state file was found! State management commands require a state file. Run this command in a directory where Terraform has been run or use the -state flag to point the command to a specific state location. $ echo $? 1 ``` ### Workaround ```shell $ terraform init -backend-config="bucket=${BUCKETNAME}" \ -backend-config="key=terraform.tfstate" \ -backend=true \ -get=true \ -input=false # This will push the "empty" state file to the backend # $ terraform state push .terraform/terraform.tfstate # See comment from @jbardin below. $ terraform state list || true ``` ### Additional Context We roll out terraform in CI/CD (concourse). The terraform configuration will be applied on multiple existing and new environments. We don't have the full control, when changes of the configuration will be rolled out to the actual environments. -> Different states across all environments In the past we had some breaking changes in the configuration (restructuring modules, changing the source of the provider, etc.), which brought the need to manipulate the state during CI/CD rollout (e.g. by using `terraform state mv` and `terraform state replace-provider`) to avoid failing executions (provider source changed) and unnecessary recreation of resources (resource moved from module to root). The state manipulations are working fine on existing infrastructure, but are failing on new (empty) environments. It seems, that the state commands (read and write) are only checking the remote state and are failing, if the state is not a the expected place. I see two possible mitigations: 1. When remote state does not exist, upload empty state on `init` 2. For all `state` commands, check local/temporary state file, if remote state does not exist