[Bug]: after using v.5.48.00 (last version was 5.47.00), tags and tags_all on aws_fsx_ontap_storage_virtual_machine resource are recreated systematically, comportment that we haven't before with v. 5.47.00

[philippecotter]

Terraform Core Version

1.5.1

AWS Provider Version

5.48.00,5.47.00

Affected Resource(s)

aws_fsx_ontap_storage_virtual_machine

Expected Behavior

Using the freshly upgraded provider (5.48.00), we normally have no change to push
and we systematically have in place update of the TAGS and TAGS_ALL values.
We use the resource's TAGS and we never had this comportment until passing the the 5.48.00 version.

Actual Behavior

Now, systematically, TF server want to add TAGS and TAGS_ALL entries....
It's like the provider is not able to read the existing TAGS in AWS

Relevant Error/Panic Output Snippet

No response

Terraform Configuration Files

resource "aws_fsx_ontap_storage_virtual_machine" "svm_xxxxxxxxxxxxx" {
#
  file_system_id = aws_fsx_ontap_file_system.xxxxxxxx.id
  name           = "svm_xxxxxxxx"
#
  root_volume_security_style = "UNIX"
#
  svm_admin_password = var.xxxxxxxxxxxxxxxxxxxxxxxxxxx
#
  active_directory_configuration {
    netbios_name = "xxxxxxxxxxxx"
    self_managed_active_directory_configuration {
      dns_ips     = xxxxxxxxxxxxxxx
      domain_name = var.SELF_MANAGED_AD_DNS
      password    = var.SELF_MANAGED_AD_PWD
      username    = var.SELF_MANAGED_AD_USERNAME
      file_system_administrators_group = var.SELF_MANAGED_AD_GROUP
      organizational_unit_distinguished_name = var.SELF_MANAGED_AD_OU
    }
  }

  tags = {
    Name              = "xxxxxxxxxxxxx"
    Platform          = "FILESHARE-FSXN"
    Environment       = "Production"
    ServiceMapping    = "xxxxxxxxxxxxxxxxxx"
    Application       = "xxxxxxxxxxxxxxxxxxe"
    Description       = "xxxxxxxxxxxxx"
    coverage          = "xxxxxxxxxxxxxxxx"
    Maison            = "xxxxxxxxxxxxxxxxx"
    PowerPolicy       = "xxxxxxxxxxxxxxx"
    INC               = "xxxxxxxxxxxxxxxxxxxxx"
    InternetPublished = "No"
  }

  lifecycle {
    ignore_changes = [
      svm_admin_password,
      active_directory_configuration
      ]
  }

  depends_on = [
    aws_fsx_ontap_file_system.xcft00103
  ]
}

Steps to Reproduce

just un-fix the version of the provider (so using the latest one, v. 5.48.00)

Debug Output

  # aws_fsx_ontap_storage_virtual_machine.svm_xxxxxxxxxx2 will be updated in-place
  ~ resource "aws_fsx_ontap_storage_virtual_machine" "svm_xxxxxxxxx" {
        id                         = "svm-xxxxxxxxxxxxxxxxxxxxxxxxxxx"
        name                       = "svm_xxxxxxxxxxx"
      ~ tags                       = {
          + "Application"       = "Cloud Files Share"
          + "Description"       = "xxxxxxx"
          + "Environment"       = "Production"
          + "INC"               = "xxxxxxxxxxx"
          + "InternetPublished" = "No"
          + "Maison"            = "xxxxxxxxxxxxx"
          + "Name"              = "svm_xxxxxxxxxxxxxxx"
          + "Platform"          = "xxxxxxxxxxxxxxxx"
          + "PowerPolicy"       = "24/7"
          + "ServiceMapping"    = "xxxxxxxxxxxx"
          + "coverage"          = "24/7"
        }
      ~ tags_all                   = {
          + "Application"       = "Cloud Files Share"
          + "Description"       = "xxxxxxx"
          + "Environment"       = "Production"
          + "INC"               = "xxxxxxxxxxx"
          + "InternetPublished" = "No"
          + "Maison"            = "xxxxxxxxxxxxx"
          + "Name"              = "svm_xxxxxxxxxxxxxxx"
          + "Platform"          = "xxxxxxxxxxxxxxxx"
          + "PowerPolicy"       = "24/7"
          + "ServiceMapping"    = "xxxxxxxxxxxx"
          + "coverage"          = "24/7"
        }
        # (7 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 81 to change, 0 to destroy.

Panic Output

Important Factoids

no

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

[ewbankkit]

Relates #36511.

We are seeing this problem in our CI:

=== RUN   TestAccFSxONTAPStorageVirtualMachine_tags
=== PAUSE TestAccFSxONTAPStorageVirtualMachine_tags
=== CONT  TestAccFSxONTAPStorageVirtualMachine_tags
    ontap_storage_virtual_machine_test.go:209: Step 1/4 error: Check failed: Check 2/3 error: aws_fsx_ontap_storage_virtual_machine.test: Attribute 'tags.%' expected "1", got "0"
--- FAIL: TestAccFSxONTAPStorageVirtualMachine_tags (2759.81s)

[github-actions]

Warning

This issue has been closed, meaning that any additional comments are hard for our team to see. Please assume that the maintainers will not see them.

Ongoing conversations amongst community members are welcome, however, the issue will be locked after 30 days. Moving conversations to another venue, such as the AWS Provider forum, is recommended. If you have additional concerns, please open a new issue, referencing this one where needed.

[github-actions]

This functionality has been released in v5.49.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.