[Bug]: Provider state compatibility issues when downgrading from v6.x to v5.x - "failed to decode identity: unsupported attribute" errors

[derkmingfong]

Terraform and AWS Provider Version

Terraform v1.12.2
on windows_amd64
+ provider registry.terraform.io/hashicorp/aws v6.0.0
+ provider registry.terraform.io/hashicorp/external v2.3.5
+ provider registry.terraform.io/hashicorp/local v2.5.3
+ provider registry.terraform.io/hashicorp/null v3.2.4
+ provider registry.terraform.io/hashicorp/random v3.7.2

Affected Resource(s) or Data Source(s)

.terraform\modules\clinical_module_ecs.ecs\modules\service\main.tf

Expected Behavior

No error

Actual Behavior

Error: failed to decode identity: unsupported attribute "account_id". This is most likely a bug in the Provider, providers must not change the identity schema without updating the identity schema version

when using latest v6.0.0

Error: Unsupported block type
│
│ on .terraform/modules/clinical_module_ecs.ecs/modules/service/main.tf line 635, in resource "aws_ecs_task_definition" "this":
│ 635: dynamic "inference_accelerator" {
│
│ Blocks of type "inference_accelerator" are not expected here.
when using v5.92.0 or v5.81.0

Relevant Error/Panic Output

Sample Terraform Configuration

Click to expand configuration

Steps to Reproduce

1. terraform init --backend-config tf.conf -upgrade
2. terraform workspace select $TF_ENV
3. terraform plan -out $TF_ENV.tfplan -var-file="variables/$TF_ENV.tfvars"

Debug Logging

Click to expand log output

GenAI / LLM Assisted Development

n/a

Important Facts and References

No response

Would you like to implement a fix?

No

[github-actions]

Community Guidelines

This comment is added to every new Issue to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Issue and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.
• For new resources and data sources, use skaff to generate scaffolding with comments detailing common expectations.

[justinretzolk]

Hey @derkmingfong 👋 Thank you for taking the time to raise this! In order to look into the account_id error you received, we'll need a sample configuration that can be used to reproduce the issue. Without that information, it's difficult to tell what might be causing that.

As far as the Blocks of type "inference_accelerator" are not expected here. when using version v6.0.0, that's expected behavior, as that argument was removed in version v.6.0.0 (release notes are here).

[derkmingfong]

Hi @justinretzolk Thanks for getting back to me.

Due to Non-Disclosure Agreement, there is a limit on how much to share my Terraform configuration.

For the error block below , we were able to remove this error, by upgrading our terraform provider aws from 5.83.0 ->5.91.0 -> 6.0.0

Error: failed to decode identity: unsupported attribute "account_id". This is most likely a bug in the Provider, providers must not change the identity schema without updating the identity schema version.

However we encountered this issue through our CI workflow, which does terraform plan

Blocks of type "inference_accelerator" are not expected here.

Upon further investigation, we found "inference_accelerator" still in the modules packages <.terraform\modules\clinical_module_ecs.ecs\modules\service\main.tf> after terraform init --upgrade

line 264 - line 650

dynamic "ephemeral_storage" {
    for_each = length(var.ephemeral_storage) > 0 ? [var.ephemeral_storage] : []

    content {
      size_in_gib = ephemeral_storage.value.size_in_gib
    }
  }

  execution_role_arn = try(aws_iam_role.task_exec[0].arn, var.task_exec_iam_role_arn)
  family             = coalesce(var.family, var.name)

  # dynamic "inference_accelerator" {
  #   for_each = var.inference_accelerator

  #   content {
  #     device_name = inference_accelerator.value.device_name
  #     device_type = inference_accelerator.value.device_type
  #   }
  # }

  ipc_mode     = var.ipc_mode
  memory       = var.memory
  network_mode = var.network_mode
  pid_mode     = var.pid_mode

  dynamic "placement_constraints" {

In our own local deployment we able to comment this section reference to "inference_accelerator", but our CI does not have that option to comment since we do not push the .terraform folder

Summary, we are still able to deploy terraform changes to aws with v6.0.0 but our CI fails constantly due to "inference_accelerator"

[justinretzolk]

Thanks for the update here @derkmingfong. Totally understand the limitations on sharing due to NDAs. As far as the inference_accelerator argument goes, it sounds like the module you're using in your CI needs to be updated to remove that argument, since the argument was removed in v6.0.0.

As far as the account_id error -- are you able to tell me what resource is listed in the error so I can attempt to reproduce? On a quick check, it doesn't seem like the aws_ecs_task_definition resource ever had an account_id attribute, so I suspect it's related to a different resource.

[derkmingfong]

Hi @justinretzolk , agreed on your remark on the updating CI to remove the "inference_accelerator".

Below is the code snippet for terraform init in CI workflow

      - name: Terraform init
        id: init
        run: >
          terraform init 
          -backend-config="bucket=$TF_STATE_S3_BUCKET" 
          -backend-config="key=$TF_STATE_KEY" 
          -backend-config="region=$AWS_REGION" 
          -backend-config="dynamodb_table=$TF_STATE_DYNAMODB_TABLE"

          terraform workspace select ${{ env.TERRAFORM_ENV }} || terraform workspace new ${{ env.TERRAFORM_ENV }}

For the variable "account_id", we are not using in the aws_ecs_task_definition but in other aws service like IAM, SQS and others .

We never had problems with it before as we have used it to add new terraform configurations before the v6.0.0.

For extra context, we are using Terraform v1.12.2 in both the CI and locally

[aristosvo]

@justinretzolk Chipping in here, as I see this error happening on our end as well. I am already testing in another branch with 6.0.0, but error is happening on a 5.100.0 provider branch and started recently erroring out (around the start of our testing on 6.0.0 in the separate branch). For us this is part of a Terratest for SCPs/ObjectLock, so I am able to share all configuration there:

TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[0m�[1mdata.aws_kms_alias.default: Reading...�[0m�[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[0m�[1mdata.aws_kms_alias.default: Read complete after 0s [id=arn:aws:kms:eu-central-1:975050113385:alias/default-key-landing-zone-test-npe-euc1-975050113385]�[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[31m╷�[0m�[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[31m│�[0m �[0m�[1m�[31mError: �[0m�[0m�[1mfailed to decode identity: unsupported attribute "account_id". This is most likely a bug in the Provider, providers must not change the identity schema without updating the identity schema version�[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[31m│�[0m �[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[31m│�[0m �[0m�[0m
TestTerraformAwsS3ObjectLock 2025-06-26T22:33:30Z logger.go:67: �[31m╵�[0m�[0m

Just a random S3 bucket, but with object lock which should fail in our case as that is blocked via an SCP:

variable "region" {
  type        = string
  description = "The region to execute tests in"
  default     = "eu-central-1"
}

variable "test" {
  type        = string
  description = "The test name to pass in tags"
  default     = "scp-test-sad"
}

data "aws_kms_alias" "default" {
  name = "alias/xxx"
}

resource "aws_s3_bucket" "bucket" {}

resource "aws_s3_bucket_object_lock_configuration" "lock" {
  bucket = aws_s3_bucket.bucket.bucket

  object_lock_enabled = "Enabled"
  rule {
    default_retention {
      days = 1
      mode = "GOVERNANCE"
    }
  }
}

resource "aws_s3_bucket_versioning" "versioning" {
  bucket = aws_s3_bucket.bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_ownership_controls" "ownership" {
  bucket = aws_s3_bucket.bucket.id
  rule {
    object_ownership = "BucketOwnerEnforced"
  }
}

resource "aws_s3_bucket_public_access_block" "block" {
  bucket                  = aws_s3_bucket.bucket.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enc" {
  bucket = aws_s3_bucket.bucket.id
  rule {
    bucket_key_enabled = true
    apply_server_side_encryption_by_default {
      kms_master_key_id = data.aws_kms_alias.default.target_key_arn
      sse_algorithm     = "aws:kms"
    }
  }
}

[certifiedcka]

The error "Blocks of type "inference_accelerator" are not expected here." can be reproduced using the example from terraform aws ecs module at https://github.com/terraform-aws-modules/terraform-aws-ecs.git. Running 'terraform validate' in the 'examples\ec2-autoscaling' directory reproduces this error.
I also faced this issue today after updating the provider to 6.0.0.

[certifiedcka]

This is not a provider issue, the AWS provider v6.0.0 upgrade states the unsupported value in its upgrade document https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-6-upgrade#data-source-aws_ecs_task_definition. I had not pinned the AWS provider version earlier, pinning the major version to 5, installs v5.100.0 and this error is resolved with AWS provider version 5.100.1. Will have to wait for the Terraform ECS module to release a version supporting AWS provider v6 before upgrading to it.