Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pagerduty_incident_workflow_trigger removes a service and adds it again causing each and every terraform plan to have 1 change. #969

Open
nmistry24 opened this issue Jan 14, 2025 · 0 comments

Comments

@nmistry24
Copy link

Terraform Version
Terraform v1.10.4

PagerDuty Provider Version
v3.18.3


Affected Resource(s)

  • pagerduty_incident_workflow_trigger

Terraform Configuration Files

# Example of incident workflow trigger
resource "pagerduty_incident_workflow_trigger" "example_trigger" {
  name         = "Example Workflow Trigger"
  conditions   = {...} # conditional logic for the trigger
  services     = [pagerduty_service.service_1.id, pagerduty_service.service_2.id, pagerduty_service.service_3.id]
  workflow_id  = pagerduty_incident_workflow.example_workflow.id
  
# Had to add the below block to prevent this issue
  lifecycle {
    ignore_changes = [services]
  }
}

Expected Behavior
If no changes are made to the trigger, its associated incident workflow, or the list of services it monitors, the terraform plan or terraform apply should not detect any changes.


Actual Behavior
Every time terraform plan or terraform apply is run, it detects a change in the pagerduty_incident_workflow_trigger resource, even when there are no actual changes to the trigger, workflow, or services.

The detected change consistently shows the removal and re-addition of a service ID in the services list. For example:

~ services = [
      "service_id_1",
    - "service_id_2",
    + "service_id_2",
      "service_id_3",
  ]

This issue causes unnecessary updates in the plan, requiring approvals for applying the changes, even when no actual updates are required.


Steps to Reproduce

  1. Create an incident_workflow_trigger resource in Terraform that includes a list of services.
  2. Ensure no changes are made to the trigger, workflow, or services.
  3. Run terraform plan or terraform apply.
  4. Observe that the plan detects changes related to removing and re-adding a service ID in the services list.

Likely Cause
The provider does not maintain any consistent ordering or sorting for the services list in the incident_workflow_trigger resource. Terraform interprets this unordered behavior as a change in the list's structure, even though the content remains the same.


Temporary Workaround
To suppress these unnecessary changes, we have implemented the lifecycle -> ignore_changes meta-argument for the services attribute:

lifecycle {
  ignore_changes = [services]
}

While this suppresses the false-positive changes in the plan, it is not an ideal solution. If there are legitimate updates to the services list, this workaround would ignore those changes, potentially causing the incident workflow and trigger to break.


Impact of the Issue

  • Unnecessary confusion during every terraform plan or terraform apply, as it always shows changes where none exist.
  • Version bump plans also detect this as a change, causing them to become full runs that require approval before applying, which disrupts efficient workflows.
  • Suppressing the changes using ignore_changes can lead to broken workflows if legitimate updates to the services list are overlooked.

Suggested Resolution
Ensure the services list or other lists in the incident_workflow_trigger resource is ordered or sorted consistently in the provider. This would prevent Terraform from detecting false changes and eliminate the need for the ignore_changes workaround, improving reliability and efficiency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant