azurerm_monitor_diagnostic_setting - wait resource to become ready in creation

[teowa]

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave "+1" or "me too" comments, they generate extra noise for PR followers and do not help prioritize for review

Description

Wait until the resource is ready in creation. The wait logic is to query the status at a minimum interval of 5 seconds until 3 consecutive response return that the resource exists. And if the resource doesn't exist the interval increases exponentially according to

terraform-provider-azurerm/vendor/github.com/hashicorp/terraform-plugin-sdk/v2/helper/retry/state.go

Lines 185 to 190 in e39139b

	// Wait between refreshes using exponential backoff, except when
	// waiting for the target state to reoccur.
	if targetOccurence == 0 {
	wait *= 2
	}

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevent documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

Test result is OK. The failed test is because of subscription issue The limit of 5 diagnostic settings was reached

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_monitor_diagnostic_setting - wait resource to become ready in creation

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

Fixes #25676
Fixes #25667

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

[rcskosir]

@teowa Thank you for using our new PR template, can you please update to include a description for this PR under the Description header? This helps with traceability for our users.

[JoDexsph]

Thanks for your contribution!

[jackofallops]

Thanks @teowa. One comment to address, which will also need applying to the delete function for the same bug.

Can you also open an issue on the API Specs for this resource as the need for this suggests that the API call should in fact be an LRO with a poller if the resource is only completed async? Please include the issue link as a comment so we can track it and update if/when it is addressed.

Thanks!

[jackofallops]

Can we use the calculated deadline from the context here otherwise that will potentially expire before this WaitForStateContext is complete. e.g.

	deadline, ok := ctx.Deadline()
	if !ok {
		return fmt.Errorf("could not retrieve context deadline for %s", id.ID())
	}

...

	Timeout: time.Until(deadline)

Can you also update the other instance(s) of this bug in this resource while we're here?

[katbyte]

@teowa - this is gtg i think once the rest api specs issue is opened anc linked to in the code via a comment

[aliciaclark1066]

Any ETA on merging this fix? Thanks!

[teowa]

Hi @aliciaclark1066 , I am not sure if it is unstable API or other factor, I cannot repro the Root resource was present, but now absent. error for diagnostic setting in my local now. Can you or anyone help provide Terraform debug logs with HTTP logs about PUT diagnostic setting and GET diagnostic setting (I guess it should be 404 returned for the GET after PUT), so I can submit the issue to REST API as suggested in #25697 (review) and push this forward.

[aliciaclark1066]

Hi @teowa, I appreciate your patience. Here are my terraform logs. Please let me know if you need anything else.
terraform.log

[teowa]

Hi @teowa, I appreciate your patience. Here are my terraform logs. Please let me know if you need anything else. terraform.log

Hi @aliciaclark1066 , thanks for providing the debug log. But the provided log is not available for this PR. I can find Provider produced inconsistent result after apply errors for the Public IP and NSG resources, however the provided log does not contain any error for Diagnostic Setting, which this PR targets. This PR will not fix issue for those network resources. So we still need the logs for Diagnostic Setting.

[teowa]

Close this for now because I am unable to repro the error thus unable to file a issue to REST API as suggested in #25697 (review), if anyone still meet the Root resource was present, but now absent. error for Monitor Diagnostic Setting, please ping me and provide the debug log so I can push this forward. Thanks.

[github-actions]

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