Terraform-provider-azurerm: Empty custom_webhook_payload is enabled by default for query_rules_alert

[hashibot[bot]]

_This issue was originally opened by @vsotog as hashicorp/terraform#24817. It was migrated here as a result of the provider split. The original body of the issue is below._

---

Terraform Version

Terraform v0.12.24

Terraform Configuration Files

I'm taking the sample configuration from the documentation

# Example: Alerting Action with result count trigger
resource "azurerm_monitor_scheduled_query_rules_alert" "example" {
  name                = format("%s-queryrule", var.prefix)
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name

  action {
    action_group           = []
    email_subject          = "Email Header"
    # (This is an optional parameter) -> custom_webhook_payload = "{}"
  }
  data_source_id = azurerm_application_insights.example.id
  description    = "Alert when total results cross threshold"
  enabled        = true
  # Count all requests with server error result code grouped into 5-minute bins
  query       = <<-QUERY
  requests
    | where tolong(resultCode) >= 500
    | summarize count() by bin(timestamp, 5m)
  QUERY
  severity    = 1
  frequency   = 5
  time_window = 30
  trigger {
    operator  = "GreaterThan"
    threshold = 3
  }
}

Debug Output

Crash Output

Expected Behavior

Custom webhook payload (empty payload) shouldn't be enabled by default.

Actual Behavior

An empty payload is enabled by default, even when not using the custom_webhook_payload parameter, causing the alert to send an empty message every time.

Steps to Reproduce

Additional Context

References

[magodo]

@vsotog Thank you for letting us know this issue :+1:
Currently, the custom_webhook_payload has a default value of {} when absent, which incurs the issue you are facing now. I will submit a PR to change this behavior, i.e. not set it at all when absent. However, that should be a breaking change and need more thoughts to see how to manage the release of this change.

[vsotog]

@magodo Hi! Any updates on this?

[magodo]

@vsotog As this change is a breaking change, we'll deliver it in v3.0.

[alk-jozog]

Hi, is there any workaround in the meantime? I didn't find a way to disable the custom webhook.

[knuthalvor]

Also interested to hear if there is a workaround for this.

[magodo]

The only thing I can think of to workaround this is to mark the custom_webhook_payload with ignore_changes, then disable it via other means (e.g. Portal).

[tombuildsstuff]

You can also set the field to an empty string to achieve the same thing e.g. custom_webhook_payload = "" since Terraform differentiates an empty string and null - however that'd need the validation to be updated to temporarily allow either a Json blob (as today) or an empty string to be set - maybe we can add that until 3.0?

[magodo]

@tombuildsstuff
Good idea! Shall I submit another PR to relax the validation and also updat the document for those who are blocked by this?

[tombuildsstuff]

@magodo that'd be great if you don't mind :)

[magodo]

👏

I just noticed there is a PR #7838 has been merged in v2.21.0, which removes the default value for custom_webhook_payload. So users provision a new monitor_scheduled_query_rule_alert can simply omit that field to disable the custom webhook. On the other hand, for those who already have the resource provisioned, you can simply disable the custom webhook on portal and then comment the custom_webhook_payload in your terraform config, and optionally run a terraform plan to verify there is no diff.

I'm going to close this issue for now.

[hashibot[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!