Not possible to delete uptime check (google_monitoring_uptime_check_config)

[jaceq]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

v1.0.5

provider: 3.86.0

Affected Resource(s)

google_monitoring_uptime_check_config

Debug Output

---[ REQUEST ]---------------------------------------
DELETE /v3/projects/some-project/uptimeCheckConfigs/someCheck?alt=json HTTP/1.1
Host: monitoring.googleapis.com
User-Agent: Terraform/1.0.5 (+https://www.terraform.io) Terraform-Plugin-SDK/2.5.0 terraform-provider-google/3.86.0
Content-Type: application/json
Accept-Encoding: gzip

This get 400 back from API saying it contains invalid argument

Panic Output

Error: Error when reading or editing UptimeCheckConfig: googleapi: Error 400: Request contains an invalid argument.

Expected Behavior

Check should get deleted.

Actual Behavior

Check doesn't get deleted and TF throws an error

Steps to Reproduce

1. Configure an uptime check
2. terraform apply
3. Change configuration in a way that forces a replacement (eg. hostname)
4. terraform apply (deletion fails)

Important Factoids

References

• #0000

b/305279561

[melinath]

I can't reproduce this - could you please add an example minimal terraform configuration that demonstrates this behavior?

[jaceq]

Hi @melinath , sorry for such a delay.

I have also tried to reproduce this on a clean state and found that this is happening when there is an alerting policy defined for such check, following tf config is affected:

resource "google_monitoring_uptime_check_config" "http" {
  project      = "some-project"
  display_name = "http-uptime-check-33"
  timeout      = "60s"
  period       = "60s"
  http_check {
    path           = "/somdde-path"
    port           = "443"
    request_method = "GET"
    use_ssl        = true
    validate_ssl   = false
  }

  monitored_resource {
    type = "uptime_url"
    labels = {
      project_id = "some-project"
      host       = "google.com"
    }
  }

  content_matchers {
    content = "example"
    matcher = "CONTAINS_STRING"
  }
  selected_regions = ["EUROPE", "USA"]
}

resource "google_monitoring_alert_policy" "http" {
  project      = "some-project"
  display_name = "Dummy  Uptime check failed "
  combiner     = "OR"
  enabled      = true
  conditions {
    display_name = "condition 1"
    condition_threshold {
      filter          = "metric.type=\"monitoring.googleapis.com/uptime_check/check_passed\" resource.type=\"uptime_url\" metric.label.\"check_id\"=\"${google_monitoring_uptime_check_config.http.uptime_check_id}\""
      duration        = "0s"
      comparison      = "COMPARISON_GT"
      threshold_value = 2
      trigger {
        count = 1
      }
      aggregations {
        alignment_period     = "60s"
        per_series_aligner   = "ALIGN_COUNT"
        group_by_fields      = []
        cross_series_reducer = ""
      }
    }
  }
}

So to reproduce, make apply with above configuration, then modify a host (in monitored_resource), TF will say it needs to replace check_config and will fail on trying to destroy.

[callensm]

I'm also encountering the same bug where a uptime check config period update forces a resource replacement and the API is failing on deletion with Error: Error when reading or editing UptimeCheckConfig: googleapi: Error 400: Request contains an invalid argument. when there is an associated alert policy tied to the configuration.

[uda]

I also encountered this issue exactly as described, an uptime check with a linked alert policy cannot be destroyed+created, I didn't check if just destroy works, which I assume will work because the policy depends on details from the uptime check and will be destroyed first so the uptime check delete won't fail.

For now, Since it isn't something we do often, I opted for the ugly workaround, deleted the relevant policies, planned and applied. The uptime checks were destroyed, created and then the alert policies were created from fresh, which is a good enough result for my use case.

[Pinolo]

This issue is solved/mitigated by the solution highlighted in #3133 (comment)

I only wish it was documented, since I think it's a common use case and nobody should be requested to infer the logical lifecycle of GCP resources behind a generic 400 error code

[jdurelli]

I will add an error message for 400s that mentions making sure all Alert Policies are deleted first.

[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.