This is a bug in the provider

[Tony-WangQAQ]

Describe the bug
When I configure dynatrace problem notification through terraform, the headers parameter is abnormal. This is very strange. The same configuration is normal when it is created for the first time. However, when I change some configurations (such as changing the configuration status to true) and re-run the code, this problem occurs, as shown in the attachment.

Expected behavior
The official description of dynatrace_webhook_notification configuration is as follows, "secret_value and value are mutually exclusive. Only one of those two is allowed to be specified." However, this bug seems to require both values ​​to be specified when reading the module, which is not a reasonable place.

Screenshots

Desktop (please complete the following information):

• OS: [ubuntu]
• Browser [chrome]
• Version [22.04]

[Reinhard-Pilz-Dynatrace]

Hello @Tony-WangQAQ

Would you be able to provide the HCL code for the dynatrace_webhook_notification you're using here?
I've tried to reproduce with a couple of samples, but so far wasn't able to get the results you're seeing.

thanks,
Reinhard

[Tony-WangQAQ]

Hello @Reinhard-Pilz-Dynatrace
Thanks a lot
Because there is some sensitive information in the current test code, I need to modify it. If the modification is completed, I will update it to you.
Thanks,
Tony

[Tony-WangQAQ]

Hello @Reinhard-Pilz-Dynatrace
Here is the code I used for testing：

data "dynatrace_alerting_profile" "template_alerting" {
  name = "template_alerting"
}
resource "dynatrace_webhook_notification" template_itsm_test {
    name                   = "[ServiceNow] template_itsm_test"
    insecure               = false
    active                 = true
    profile       = data.dynatrace_alerting_profile.template_alerting.id
    notify_event_merges    = false
    notify_closed_problems = false
    payload                =<<-EOT
      {
                "event_class": "BMW_Dynatrace",
                "node": "https://www.jd.com/",
                "severity": "Warning",
                "message_key": "123",
                "description": "{ProblemTitle}\nImpacted Entities: {ImpactedEntity}\nUrl: {ProblemURL}\nProblem-ID: {ProblemID}",
                "type": "[ServiceNow] template_itsm_test",
                "resource": "Environment: PROD",
                "source": "Dynatrace Managed",
                "metric_name": "Dynatrace Managed",
                "additional_info": {
                    "ars_esc": "Yes",
                    "ars_delay_time": "20",
                    "dd1": "{ProblemURL}",
                    "dd2": "{PID}",
                    "dd3": "{Tags}",
                    "dd_plus": "{ProblemSeverity}",
                    "event_id": "{ProblemID}",
                    "adapter_host": "prod",
                    "bmw_appd": "appd-111"}
      }
    EOT
    url                    = "https://www.jd.com/"
    headers { 
    header {
      name  = "key"
      value = "***"
    }
  }
  use_oauth_2            = true
  oauth_2_credentials {
    access_token_url = "https://www.jd.com/"
    client_id        = "123"
    client_secret    = "123"
    scope            = "123"
  }
}

My header value is stored in AWS secret manager. Here, I call the secret value. Since it is sensitive information, I cannot send it. Please note.
Thanks a lot,
Tony

[Reinhard-Pilz-Dynatrace]

Hi Tony,

I unfortunately still cannot reproduce that error message. But based on the wording in that error I have a hunch that it has something to do with this bug in the Terraform Plugin SDK. We have to circumvent that phenomenon in several resources. And that bit of information

cty.ObjectVal(map[string]cty.Value{"name":cty.NullVal(cty.String), "secret_value":cty.StringVal(""), "value":cty.NullVal(cty.String)})

makes me believe, that it might be the root cause.

Right now we don't have a proper way to handle this case. But with the release of the provider scheduled for tomorrow I have added something that hopefully allows you to avoid the error:

When running terraform apply or terraform plan, you need to set the environment variable DYNATRACE_FORCE_NEW_ON_HEADERS to true. In that case the provider will enforce that any changes within the headers require Terraform to recreate the whole resource.

I've hidden that feature behind an environment variable for the moment, so we can collect feedback from you first. If it is indeed a solution we will make that default behavior in the future.

Let me know once you were able to try this out with the upcoming release of the provider. I will keep this ticket open until then.

[Tony-WangQAQ]

Hello @Reinhard-Pilz-Dynatrace
Thanks very mush.
Currently I am ignoring the Header content by adding the following code.（For me, this header value is fixed and it shouldn’t change often in the future.）

lifecycle {
    ignore_changes = [
      headers
    ]
  }

Because I have other work to complete urgently, if I have enough time, I will test and verify it and feedback the results to you

Thanks a lot，
Tony

[Reinhard-Pilz-Dynatrace]

Hello @Tony-WangQAQ,

Exactly, the lifecycle block would have been the one thing I would have suggested as a temporary workaround.
We are planning to investigate different approaches for how to deal with unordered blocks where parts of the data is not getting delivered by the REST API. It is a well known issue for us. We just haven't figured out yet a way how to deal with it.

If you're ok with it, I will close this ticket until further notice. Please drop us a message once you had time to run a few tests. We'd welcome the feedback.