Open mambax opened 3 years ago
Thanks for reporting this, Dom! It looks like the retry logic is a little greedy. I'll put his on the list to address.
This is still an issue in v1.9.6
. @mambax, your assumption on actual behavior is correct. I can confirm that it will fail to destroy.
Hi! I'm using provider version 2.11.0
and I'm getting a similar error when trying to delete an user from the schedule
and team_membership
.
I tries to delete the team_membership
before deleting the user from the schedule
, so it fails because the user belongs to a schedule.
I have tried to explicit the dependency in the schedule resource:
resource "pagerduty_schedule" "primary" {
[...]
depends_on = [pagerduty_user.users, pagerduty_team_membership.team_membership]
But it didn't work and I'm still getting the error below
pagerduty_team_membership.team_membership[0]: Destroying... [id=PO21JXJ:P2A6JL1]
pagerduty_team_membership.team_membership[0]: Still destroying... [id=PO21JXJ:P2A6JL1, 10s elapsed]
pagerduty_team_membership.team_membership[0]: Still destroying... [id=PO21JXJ:P2A6JL1, 20s elapsed]
[...]
pagerduty_team_membership.team_membership[0]: Still destroying... [id=PO21JXJ:P2A6JL1, 2m0s elapsed]
Error: DELETE API call to https://api.pagerduty.com/teams/P2A6JL1/users/PO21JXJ failed 400 Bad Request. Code: 2001, Errors: [User cannot be removed as they belong to an escalation policy on this team], Message: Invalid Input Provided
The same behaviour is still happening on version 3.0.1
of the provider. The membership is only deleted if the user is the active on-call, otherwise it will fail with 400.
The call above only returns users set explicitly on the escalation policy and users which are currently on-call according to the set schedule.
This can be fixed by setting:
agerduty.ListOnCallOptions{UserIds: []string{userID}, Since: "Today", Until: "90d from today"}
Hi all, I discovered something rather un-smooth and wanted to share. Maybe the fix is straight-forward for you.
What I report makes totally sense of course. Yet the error handling of the provider or the API is very misleading.
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Before
After
Before
Panic Output
To reflect the change above TF must replace:
In words
I wanted to replace one user with another. For that I just changed the team membership (replace one member with another). But, in the schedule the old member was still used.
Expected Behavior
The API/Provider should output, that the object can not be destroyed because it is referenced in a schedule, or even in which schedule.
Can not destroy pagerduty_team_membership.TMTMTM, entity is in use in schedule pagerduty_schedule.EEE
Actual Behavior
See output. Destroy ends in an endless position (or at least I did not wait long enough).
Steps to Reproduce
Described above.
Best regards, Dom