[Bug]: aws_applicationinsights_application unexpected state with auto_config_enabled=true

[pib]

Terraform Core Version

0.13.6

AWS Provider Version

4.30.0,4.34.0

Affected Resource(s)

• aws_applicationinsights_application

Expected Behavior

It should be able to create and destroy the resource without issue.

Actual Behavior

When auto_config_enabled is true, it gets an "unexpected state" error on both create and destroy. This results in the resource being tainted on create, and then another "unexpected state" error when it destroys the resource before it can recreate it.

Relevant Error/Panic Output Snippet

Error: waiting for ApplicationInsights Application (test) create: unexpected state 'CONFIGURING', wanted target 'NOT_CONFIGURED'. last error: %!s(<nil>)

Error: waiting for ApplicationInsights Application (test) delete: unexpected state 'ACTIVE', wanted target ''. last error: %!s(<nil>)

Terraform Configuration Files

resource "aws_applicationinsights_application" "test" {
  resource_group_name = aws_resourcegroups_group.test.name

  auto_config_enabled = true
}

resource "aws_resourcegroups_group" "test" {
  name = "test"

  resource_query {
    query = jsonencode({
      ResourceTypeFilters = ["AWS::AllSupported"]
      TagFilters          = [{ Key = "test" }]
    })
  }
}

Steps to Reproduce

Apply the above config, or any applicationinsights_application with auto_config_enabled=true.

Debug Output

No response

Panic Output

No response

Important Factoids

With auto_config_enabled=false, there is no error, since the expected state of NOT_CONFIGURED is reached.

It seems like the solution would simply be to add additional possible states to the wait functions.

References

https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/applicationinsights/wait.go is the location of the wait functions where the expected states are listed.

The AWS API docs don't include any information of the actual values of the LifeCycle field, so I just watched the value in a loop as I ran apply to create and destroy an application. It's possible that it could also be in CREATING when deleting, but I wasn't able to replicate that since it goes from CREATING to the next state pretty quickly.

When creating an application, the LifeCycle goes CREATING -> [CONFIGURING] -> (ACTIVE|NOT_CONFIGURED)

When deleting an application, it goes (ACTIVE|CONFIGURING|NOT_CONFIGURED) -> DELETING -> gone

The waitApplicationCreated function would need Pending to be []string{"CREATING", "CONFIGURING"}, and Target would need to be []string{"ACTIVE", "NOT_CONFIGURED"}. Maybe "CONFIGURING" would belong in the Target slice instead? I guess it depends on whether it should wait for the application to be configured or not.

The waitApplicationTerminated function would need Pending to be []string{"ACTIVE", "CONFIGURING", "NOT_CONFIGURED", "DELETING"} ("CONFIGURING is included for the case where something else failed during apply, caused the application to be tainted, and a new apply is started before it is done configuring). Target would stay []string{}.

I would have opened a PR with these changes, but I am pretty sure the tests will need to be updated and I don't have the free time to update and add those currently.

Would you like to implement a fix?

No

[github-actions[bot]]

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.

[NelsonIg]

Is there a work around ?

[pib]

Is there a work around ?

Workaround:

After the initial apply failure, the resource will be tainted. You can terraform untaint it and it will be ok after that (unless you try to delete it, which will trigger another failure).

[NelsonIg]

exactly, i use the aws cli for the auto configuration intead. This works for applying. The Error for destroying however still remains.

[mforutan]

Is there any update on this issue?

[Jeroen-Priester]

Workaround:

Initial deploy: set auto_config_enabled = false Also make sure the resource group going to be used is empty. Since resources already detected prior to enabling auto configure will not be configured.

After initial deploy: Enable Auto config in the aws portal or with aws cli. set auto_config_enabled = true running the plan again will report: "No changes Your infrastructure matches the configuration" Now you can add resources to the resource group and will get automatically configured.

[mandzyu]

Did this change resolve the issue? https://github.com/hashicorp/terraform-provider-aws/commit/88f5cc6cd1414b3d7ffd06e3e33d9beae9cf8f9c

[jar-b]

After running a minimal configuration with auto_config_enabled = true in a loop for ~20 iterations, I was able to reproduce this behavior.

│ Error: waiting for ApplicationInsights Application (Sqlserver-third-TestRG2) create: unexpected state 'ACTIVE', wanted target 'NOT_CONFIGURED'. last error: %!s(<nil>)
│
│   with aws_applicationinsights_application.app_insights["Sqlserver-third-TestRG2"],
│   on main.tf line 44, in resource "aws_applicationinsights_application" "app_insights":
│   44: resource "aws_applicationinsights_application" "app_insights" {
│
╵

The current assumption is that all applications enter a NOT_CONFIGURED lifecycle status upon initial creation (which is why this succeeds most of the time in minimal configurations such as our acceptance test), but in some instances can proceed into an ACTIVE status before the create waiter has polled for and observed a NOT_CONFIGURED status. The AWS documentation on the LifeCycle argument is limited, so while we cannot be certain about the expected values in the lifecycle flow, there is enough evidence from issue reports and manual testing to indicate ACTIVE should be considered a valid target state.

[jar-b]

Did this change resolve the issue? 88f5cc6

Partially - it addressed the destroy failure from the initial report. The apply failure will be fixed in a separate PR that will close this issue as completed.

[github-actions[bot]]

[!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[bot]]

This functionality has been released in v5.43.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[bot]]

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.