When making updates to the database that don't involve the engine_version changing the engine version should not be changed in the modify-db-cluster request.
Actual Behavior
Due to a change to the logic to prevent the engine_version being changed when apply_immediately = false and the change is still pending, the engine_version is sent through to the AWS API as it is in the state/resource input regardless of it having been changed in code. See #30247 specifically these lines.
When using a partial version for an Aurora DB, which is supported when the database is initially created, we get the following error when we upgrade the AWS provider past v4.62.0 where this change was implemented.
Relevant Error/Panic Output Snippet
Error: updating RDS Cluster (my-db): InvalidParameterCombination: Cannot find upgrade target from 5.7.serverless_mysql_aurora.2.08.3 with requested version 5.7.mysql_aurora.2 for serverless engine mode.
Deploy the above Terraform, wait for AWS to automatically increase the database by a minor version.
Add backup_retention_period = 7, see the above error.
It is unclear if the ignore_changes is required as the need for this may have been removed in previous changes to the provider after this was introduced.
Debug Output
No response
Panic Output
No response
Important Factoids
No response
References
This was introduced in #30247 specifically these lines.
A function exists and is executed as part of the read for the resource and considers any pendingVersions. At first glance I wonder if the branching logic in this could be split into a function that returns a bool and that used in the conditional instead or some similar logic/schema changes to add pending versions into consideration.
At this point I am unable to look further into a fix and our Terraform is being fixed by re-importing the resource and pinning the minor versions.
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.4.6
AWS Provider Version
4.62.0
Affected Resource(s)
aws_rds_cluster
Expected Behavior
When making updates to the database that don't involve the
engine_version
changing the engine version should not be changed in themodify-db-cluster
request.Actual Behavior
Due to a change to the logic to prevent the
engine_version
being changed whenapply_immediately = false
and the change is still pending, theengine_version
is sent through to the AWS API as it is in the state/resource input regardless of it having been changed in code. See #30247 specifically these lines.When using a partial version for an Aurora DB, which is supported when the database is initially created, we get the following error when we upgrade the AWS provider past v4.62.0 where this change was implemented.
Relevant Error/Panic Output Snippet
Terraform Configuration Files
Steps to Reproduce
Deploy the above Terraform, wait for AWS to automatically increase the database by a minor version. Add
backup_retention_period = 7
, see the above error.It is unclear if the
ignore_changes
is required as the need for this may have been removed in previous changes to the provider after this was introduced.Debug Output
No response
Panic Output
No response
Important Factoids
No response
References
This was introduced in #30247 specifically these lines.
A function exists and is executed as part of the
read
for the resource and considers any pendingVersions. At first glance I wonder if the branching logic in this could be split into a function that returns abool
and that used in the conditional instead or some similar logic/schema changes to add pending versions into consideration.At this point I am unable to look further into a fix and our Terraform is being fixed by re-importing the resource and pinning the minor versions.
Would you like to implement a fix?
No