terraform-provider-newrelic: Error unmarshaling `newrelic_alert_channel` configuration headers after release v1.12.0

Hi there,

It appears that the attempted forwards-compatible change for deprecating configuration in the newrelic_alert_channel has broken unmarshaling of configuration headers in the PR #307, release https://github.com/terraform-providers/terraform-provider-newrelic/releases/tag/v1.12.0

Terraform Version

0.12.6

Affected Resource(s)

newrelic_alert_channel

Terraform Configuration Files

Working on v1.11.0, broken on v1.12.0

resource "newrelic_alert_channel" "slack_warning" {
  name = "Some slack channel"
  type = "slack"

  configuration = {
    channel = "#some-slack-channel"
    url     = var.slack_url
  }

  // https://github.com/terraform-providers/terraform-provider-newrelic/issues/5
  lifecycle {
    ignore_changes = ["configuration"]
  }
}

Expected Behavior

It appears as though there was an attempt to add forwards compatible support to v1.12.0 for the configuration object in order to support migration from configuration = { to config { so I would expect that to work with a deprecation warning.

Actual Behavior

While using the above Terraform configuration on v1.12.0 of the NR TF provider, I receive the following error running terraform plan. The deprecated warning is expected and we are working through the migration but the JSON unmarshal error is not expected:

Warning: "configuration": [DEPRECATED] use `config` block instead

  on .terraform/modules/newrelic-alerts/newrelic-alerts/alert_channels.tf line 1, in resource "newrelic_alert_channel" "slack_warning":
   1: resource "newrelic_alert_channel" "slack_warning" {

Error: json: cannot unmarshal string into Go struct field ChannelConfiguration.channels.configuration.headers of type map[string]string

Steps to Reproduce

terraform plan with the above example Terraform configuration and v1.12.0 of the TF NR provider

Important Factoids

It also appears that config is not backwards compatible before v1.12.0 which makes this a hard cutover (and potentially a breaking change for other consumers)

References

#307

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 25 (19 by maintainers)

Most upvoted comments

So the issue resides in the client newrelic-client-go. We’ll need a custom unmarshall method for the Header and Payload fields in the ChannelConfiguration struct. Hoping we have a fix for this released early next week.

sanderblue on Jan 18, 2020

The fix for this has been merged in the upstream client newrelic-client-go PR #102. We will be looking to release an update to the Terraform provider within the next day or so.

sanderblue on Jan 22, 2020

I also encountered this error even once I updated the configuration reference to config in my module. I no longer encounter the deprecation warning, but still see the unmarshal error.

Error: json: cannot unmarshal string into Go struct field ChannelConfiguration.channels.configuration.headers of type map[string]string

pneigel-ca on Jan 21, 2020

No problem. Thanks for the additional information. I was able to reproduce running the terraform destroy command. We’ll continue debugging and will report back. Appreciate the cooperation 😃

sanderblue on Jan 17, 2020

I know I didn’t file this ticket, but I appear to be experiencing the same problem as of provider 1.12.0/1. I get the following error trying to deserialize an email alert channel (which of course doesn’t have a payload attribute).

json: cannot unmarshal number into Go struct field ChannelConfiguration.channels.configuration.payload of type string

We have a very large, complex configuration so I can’t paste all the details, but the relevant section of the alert channel JSON response from our API calls look perfectly normal:

{ “id”: 2306972, “name”: “Name Redacted”, “type”: “email”, “configuration”: { “include_json_attachment”: “true”, “recipients”: “NameRedacted@email.com” }, “links”: { “policy_ids”: [ 424998, 424997, 424890 ] }

sgsiebers on Jan 24, 2020

We should have v1.12.2 released relatively soon. If not this evening, then Monday morning for sure. Thank you for your patience.

sanderblue on Jan 25, 2020

That sounds right to me. I was just noticing that this works for my prod account (where the webhook payloads don’t have any nested JSON), but fails in our non-prod where we do have a payload with nested JSON.

sgsiebers on Jan 24, 2020

Fairly certain we know what the issue is now. Still need to confirm 100% on this, but the issue stems from the channels that contain a payload that has any additional nesting in the JSON. Since terraform needs to get a list of your channels, any channel you have can causes this issue, so the error message is a bit misleading 😞

The structs expect payload to be something such as

{ "some_string_key": "a_string_value"}

but some of the webhook channels have a payload that is more complex with nested objects or arrays such as

{ 
  "string_key": [ "oops_an_array"] 
}

and/or

{ 
  "string_key": {
    "oops": "a nested object"
  } 
}

So we’ll need to make an additional update. Sorry for inconvenience, but we’ll try to get a fix out asap for this. In the meantime, it might be best to stick to the provider version v1.11.0 since it was working for you at that point. We’ll get back to you once the next update is released.

sanderblue on Jan 24, 2020

@sanderblue I posted the two relevant modules and instance main.tf in pastebin

This is of course running against an existing tfstate because I am managing resources that already exist.

pneigel-ca on Jan 24, 2020

Hi there! Thanks for reporting. So far I’m unable to reproduce, but do you happen to have other channel resource blocks in your HCL such as a webhook? The field ChannelConfiguration.channels.configuration.headers is part of the webhook config arguments.

sanderblue on Jan 17, 2020