newrelic_notification_destination references wrong destination

[asweet-confluent]

Terraform Version

Terraform v1.4.6
on linux_amd64
+ provider registry.terraform.io/newrelic/newrelic v3.27.1

Affected Resource(s)

• newrelic_notification_destination data source

Terraform Configuration

terraform {
  backend "local" {
    path = "state/terraform.tfstate"
  }

}
terraform {
  required_version = "1.4.6"
  required_providers {
    newrelic = {
      source  = "newrelic/newrelic"
      version = "~> 3.27.1"
    }
  }
}

provider "newrelic" {
  account_id = XXXXXXXX
  region     = "US"
}

data "newrelic_notification_destination" "slack_destination" {
  account_id = XXXXXXX
  name = "Confluent"
}

output "slack_destination" {
  value = data.newrelic_notification_destination.slack_destination
}

When looking up a newrelic_notification_destination with the name parameter, the API endpoint used seems to be doing a full text search instead of filtering to exact matches. The data source implementation grabs the first result and silently discards the rest. In some cases, this causes an unexpected destination to be used.

In my example above, the search for a notification destination named Confluent results in the following response captured using TF_LOG=debug:

{
	"data": {
		"actor": {
			"account": {
				"aiNotifications": {
					"destinations": {
						"entities": [{
								"accountId": "XXXXXXX",
								"active": true,
								"auth": {
									"authType": "TOKEN",
									"prefix": "Token token="
								},
								"createdAt": "2023-06-22T17:22:12.468027Z",
								"id": "XXXXXXX",
								"isUserAuthenticated": false,
								"lastSent": null,
								"name": "Confluent PagerDuty",
								"properties": [{
										"displayValue": null,
										"key": "source",
										"label": "terraform-source-internal",
										"value": "terraform"
									},
									{
										"displayValue": null,
										"key": "two_way_integration",
										"label": null,
										"value": "true"
									}
								],
								"status": "DEFAULT",
								"type": "PAGERDUTY_ACCOUNT_INTEGRATION",
								"updatedAt": "2023-08-22T19:00:49.682815Z",
								"updatedBy": "XXXXXXX"
							},
							{
								"accountId": "XXXXXXX",
								"active": true,
								"auth": {
									"authType": "TOKEN",
									"prefix": "Bearer"
								},
								"createdAt": "2023-04-24T18:34:44.311199Z",
								"id": "XXXXXXX",
								"isUserAuthenticated": true,
								"lastSent": null,
								"name": "Confluent",
								"properties": [{
										"displayValue": null,
										"key": "scope",
										"label": "Permissions",
										"value": "app_mentions:read,channels:join,channels:read,chat:write,chat:write.public,commands,groups:read,links:read,links:write,team:read,users:read"
									},
									{
										"displayValue": null,
										"key": "teamName",
										"label": "Team Name",
										"value": "Confluent"
									}
								],
								"status": "DEFAULT",
								"type": "SLACK",
								"updatedAt": "2023-08-21T21:39:10.178429Z",
								"updatedBy": "XXXXXXX"
							}
						],
						"error": null,
						"errors": [],
						"nextCursor": null,
						"totalCount": 2
					}
				}
			}
		}
	}
}

The response contains one Slack destination named Confluent (the expected result), and a PagerDuty destination named Confluent PagerDuty. Because the PagerDuty destination is the first result, it gets used:

Changes to Outputs:
  + slack_destination = {
      + account_id = XXXXXXX
      + active     = true
      + id         = "XXXXXXX"
      + name       = "Confluent PagerDuty"
      + property   = [
          + {
              + display_value = ""
              + key           = "source"
              + label         = "terraform-source-internal"
              + value         = "terraform"
            },
          + {
              + display_value = ""
              + key           = "two_way_integration"
              + label         = ""
              + value         = "true"
            },
        ]
      + status     = "DEFAULT"
      + type       = "PAGERDUTY_ACCOUNT_INTEGRATION"
    }

I tried the same thing on a different account with the same setup and the response order was reversed, causing the correct destination to be used. I'm guessing it's because the Slack destination on that account has a later creation date, causing it to show up first in the search results.

[pranav-new-relic]

Thank you for reporting this, @asweet-confluent. The team working actively with this resource has acknowledged this issue, and shall triage it further, based on their current task priority.

cc @amaor-newrelic

[vamshidhar-rapolu]

Facing same issue as the data source newrelic_notification_destination is returning the top result from all the destination names starting with the name attribute that's provided as the input.