Config drifting after upgrading to 0.7.0

[iarlyy]

after upgrading to 0.7.0, i am noticing the following code drift on conditions and actions

  ~ resource "sentry_rule" "alerts" {
      ~ actions      = [
          - {
              - "channel"    = "#errors"
              - "channel_id" = "REDACTED"
              - "id"         = "sentry.integrations.slack.notify_action.SlackNotifyServiceAction"
              - "name"       = "Send a notification to the REDACTED-COMPANY-NAME Slack workspace to #errors (optionally, an ID: REDACTED) and show tags [environment, url, transaction] in notification"
              - "tags"       = "environment,url,transaction"
              - "workspace"  = (sensitive)
            },
          + {
              + "channel"   = "#errors"
              + "id"        = "sentry.integrations.slack.notify_action.SlackNotifyServiceAction"
              + "tags"      = "environment,url,transaction"
              + "workspace" = (sensitive)
            },
        ]
      ~ conditions   = [
          - {
              - "id"   = "sentry.rules.conditions.first_seen_event.FirstSeenEventCondition"
              - "name" = "A new issue is created"
            },
          + {
              + "id" = "sentry.rules.conditions.first_seen_event.FirstSeenEventCondition"
            },
        ]
        id           = "9936343"
        name         = "production-app-FirstSeenEvent"

the same doesn't drift when using 0.6.0

Are you aware of any changes on sentry api? I didn't have time yet to look further.

[jianyuan]

@iarlyy Sentry APIs indeed add default values if they are not provided on creation. Could you adjust your manifest to match what is being removed?

Your manifest should look like this:

resource "sentry_rule" "alerts" {
  actions = [
    {
      channel    = "#errors"
      channel_id = "REDACTED"
      id         = "sentry.integrations.slack.notify_action.SlackNotifyServiceAction"
      name       = "Send a notification to the REDACTED-COMPANY-NAME Slack workspace to #errors (optionally, an ID: REDACTED) and show tags [environment, url, transaction] in notification"
      tags       = "environment,url,transaction"
      workspace  = "..."
    }
  ]

  conditions = [
    {
      id   = "sentry.rules.conditions.first_seen_event.FirstSeenEventCondition"
      name = "A new issue is created"
    }
  ]
}

[mced]

@jianyuan Is that make sense to you to manage this inside the provider instead?

edit: meanwhile, I see that channel attribute doesn't contain # character anymore if the alert has been created after upgrading the provider

[jianyuan]

@mced It's a bit tricky at the moment as we're using an internal API that could break at any time. The issue is that the API has a mixture of user and computed attributes that could change at any time. My preference, for now, is that whenever there is a change in computed attributes, we let the terraform state drift, and the user should update their terraform manifest to match with the latest response. I'm very much open to better ideas.

Regarding the channel attribute. Looking at the current source code of Sentry, it seems that they are distinguishing between the channel prefix and channel name. This is an example of a computed attribute that they changed that causes our terraform state to drift.

[mced]

@jianyuan you're right, but that would easier for everyone if, somewhere, the rule resource is noted as "internal api" not supported by Sentry and that can be changed anytime.

[rotilho]

Sentry seems to be ignoring the actions and condition name. Can we just remove it from the provider? The UI don't even display it anymore

[richardsimko]

This is still a problem with Slack alerts even after matching the state in the manifest:

All attributes are the same so the only diff I can see is the ordering of the attributes, however first of all that shouldn't affect anything (I don't know enough about TF so maybe order matters) second of all the order is correct in my manifest but still gets swapped around when the plan is run.

[pballandras]

I'm late to the party 😅 While this is just a temporary fix, I found that, by using Terraform's built-in lifecycle feature, I was able to make drift go bye-bye. I did something like that:

resource "sentry_rule" "rule" {
 ...

  conditions = [
    {
      id   = "sentry.rules.conditions.first_seen_event.FirstSeenEventCondition"
      name = "A cool name with explosions"
    },
    {
      id   = "sentry.rules.conditions.regression_event.RegressionEventCondition"
      name = "Cooler name, but with less explosions"
    },
    ...
  ]

  actions = [
    {
      id   = "sentry.rules.actions.notify_event.NotifyEventAction"
      name = "Tokyo Drift"
    },
    {
      id        = "sentry.integrations.slack.notify_action.SlackNotifyServiceAction",
      name      = "Send a notif to #phil-doing-tests-2022"
      channel   = "#phil-doing-tests-2022",
      workspace = 1,
    },
    ...
  ]
  lifecycle {
    ignore_changes = [
      actions[0]["channel_id"],
      actions[0]["name"],
      conditions[0]["name"],
      actions[1]["channel_id"],
      actions[1]["name"],
      conditions[1]["name"],
      ...
      actions[n]["channel_id"],
      actions[n]["name"],
      conditions[n]["name"]
    ]
  }

}

Cheers guys!

[jianyuan]

Continue discussions in #200