<!-- Hi there, Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html. If your issue relates to Terraform Cloud/Enterprise, please contact tf-cloud@hashicorp.support. If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://registry.terraform.io/browse/providers. To fix problems, we need clear reproduction cases - we need to be able to see it happen locally. A reproduction case is ideally something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context. * A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed * Please include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource * Set defaults on (or omit) any variables. The person reproducing it should not need to invent variable settings * If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. Providing a script can be easier than explaining what changes to make to the config between runs. * Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug * When possible, use the [null resource](https://www.terraform.io/docs/providers/null/resource.html) provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases. --> ### Terraform Version ``` ╰─ terraform version Terraform v1.0.9 on darwin_amd64 + provider registry.terraform.io/hashicorp/aws v3.37.0 + provider registry.terraform.io/hashicorp/random v3.1.0 ``` ### Terraform Configuration Files <!-- Paste the relevant parts of your Terraform configuration between the ``` marks below. For Terraform configs larger than a few resources, or that involve multiple files, please make a GitHub repository that we can clone, rather than copy-pasting multiple files in here. For security, you can also encrypt the files using our GPG public key at https://www.hashicorp.com/security. --> ```terraform terraform { backend "s3" { bucket = "my-tfstate-bucket" key = "kubernetes-infra.tfstate" region = "us-west-2" workspace_key_prefix = "tf-state" profile = "test-account/administrator" } } ``` ### Debug Output ``` 2021-10-27T16:38:34.408-0700 [DEBUG] [aws-sdk-go] DEBUG: Request s3/PutObject Details: ---[ REQUEST POST-SIGN ]----------------------------- PUT /tf-state/dnozay_testing/kubernetes-infra.tfstate HTTP/1.1 Host: xxxxxx User-Agent: aws-sdk-go/1.40.25 (go1.16.4; darwin; amd64) APN/1.0 HashiCorp/1.0 Terraform/1.0.9 Content-Length: 155 Authorization: xxxxxx Content-Md5: xxxxxx Content-Type: application/json X-Amz-Content-Sha256: xxxxxx X-Amz-Date: xxxxxx X-Amz-Security-Token: xxxxxx Accept-Encoding: gzip { "version": 4, "terraform_version": "1.0.9", "serial": 0, "lineage": "xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx", "outputs": {}, "resources": [] } ``` ### Expected Behavior Creating a new workspace should work and use input state as base. ``` terraform state pull > tf.state.default terraform workspace new -state=tf.state.default ${USER}_testing ``` - This issue may be specific to s3 backend / s3 remote state - I do not see this issue when using gcs remote state ### Actual Behavior - Initialized with empty state. ### Steps to Reproduce ``` terraform workspace select default terraform state pull > tf.state.default ls -lh tf.state.default echo "number of resources=$(terraform state list | wc -l)" terraform workspace delete -force ${USER}_testing TF_LOG=trace terraform workspace new -state=tf.state.default ${USER}_testing echo "number of resources=$(terraform state list | wc -l) 😭😭😭" terraform state push tf.state.default echo "number of resources=$(terraform state list | wc -l)" ``` ### Additional Context without `TF_LOG=trace` ``` Switched to workspace "default". -rw-r--r-- 1 dnozay staff 281K Oct 27 16:45 tf.state.default number of resources= 205 Deleted workspace "dnozay_testing"! WARNING: "dnozay_testing" was non-empty. The resources managed by the deleted workspace may still exist, but are no longer manageable by Terraform since the state has been deleted. Created and switched to workspace "dnozay_testing"! You're now on a new, empty workspace. Workspaces isolate their state, so if you run "terraform plan" Terraform will not see any existing state for this configuration. number of resources= 0 😭😭😭 number of resources= 205 ``` As you can see in the steps, workaround is to explicitly push the state ``` terraform state push tf.state.default ``` However, this is using the same `lineage` which could be a problem. In that regard, S3 backend and GCS backend are not working the same.