aws_docdb_subnet_group and aws_docdb_cluster_parameter_group
Expected Behavior
When using our documentdb module with version ~>1.3 of terraform and ~>5.0 of provider the upgrade to 1.8 should be transparent.
Actual Behavior
The pipeline of the service using the documentdb resources fails with the following error
Relevant Error/Panic Output Snippet
Error: Provider produced inconsistent final plan
│
│ When expanding the plan for aws_docdb_cluster_parameter_group.this to
│ include new values learned so far during apply, provider
│ "registry.terraform.io/hashicorp/aws" produced an invalid new value for
│ .tags_all: new element "module_version" has appeared.
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
Note that I get multiple errors with all tags, not just module_version
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers 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.
Terraform Core Version
~>1.8
AWS Provider Version
~> 5.0
Affected Resource(s)
aws_docdb_subnet_group and aws_docdb_cluster_parameter_group
Expected Behavior
When using our documentdb module with version ~>1.3 of terraform and ~>5.0 of provider the upgrade to 1.8 should be transparent.
Actual Behavior
The pipeline of the service using the documentdb resources fails with the following error
Relevant Error/Panic Output Snippet
Note that I get multiple errors with all tags, not just module_version
The way we declare are tags:
in locals.tf
in providers.tf
Terraform Configuration Files
Steps to Reproduce
Change the versions.tf file from terraform 1.3 to 1.8 and re-deploying the services that is using the documentdb module
Debug Output
No response
Panic Output
No response
Important Factoids
Tried downgrading provider version down to 5.10.0 but same error appears. When rolling back to terraform 1.3 the error disappears.
References
No response
Would you like to implement a fix?
None