opsgenie_alert_policy conditions order is not stable causing "in-place" updates though nothing changes

[trezu76]

I have same issue as this one but this time for alert policies

Terraform and provider Version

1.1.9 0.6.25

Affected Resource(s)

opsgenie_alert_policy

References

https://github.com/opsgenie/terraform-provider-opsgenie/issues/332 https://github.com/opsgenie/terraform-provider-opsgenie/pull/338

[ahuseby]

I ran into the same issue. Tried setting the order attribute hoping that it'd solve the problem, but it seems the Policy API sorts the filter conditions list according to something other than that.

Here's an example of API response

{
  "data": {
    "type": "alert",
    "continue": true,
    "name": "Policy Name",
    "enabled": true,
    "policyDescription": "Policy Description",
    "id": "1234abc-uuid-5678def",
    "filter": {
      "type": "match-any-condition",
      "conditions": [
        {
          "field": "extra-properties",
          "key": "AWSAccountId",
          "not": false,
          "operation": "equals",
          "expectedValue": "012345678901",
          "order": 2
        },
        {
          "field": "extra-properties",
          "key": "AWSAccountId",
          "not": false,
          "operation": "equals",
          "expectedValue": "987654321098",
          "order": 7
        },
        ...
      ]
    },
    ...
}

As you can see, the first element of the "conditions" list has the order attribute set to 2. Regardless of the order attribute, it seems that the API sorts the list of conditions according to something else, then when Terraform compares its state to the API response upon plan, the order is completely different according to the configuration, hence perpetual plan diff.

~Perhaps somehow make the provider not care about the particular order/indecies of the API's "conditions" list?~ A solution similar to https://github.com/opsgenie/terraform-provider-opsgenie/pull/338 is probably going to fix it, as referenced by OP :)

[koushik-swaminathan]

This should be fixed in the latest release v0.6.30, closing this issue for now.