While trying to add DIDs to architect_ivr object, if any of the new DIDs errors out, some of the existing DIDs also get wiped out. We are using client version 1.28.0, but this is not a new issue as far as I'm aware.
This is causing routing issues until we either roll back the change or fix the source of the error so that all the DIDs get added back in.
For example, attempting to add 17 DIDs below. The first run errors out, and the second run is showing 600+ DID changes.
module.architect_ivr.genesyscloud_architect_ivr.xxx will be updated in-place
~ resource "genesyscloud_architect_ivr" "xxx" {
~ dnis = [
+ <<<17 DIDs to be added>>>
# (680 unchanged elements hidden)
...
Result:
error occured updating ivr yyy in function uploadDnisChunk: API Error: 400 - PhoneNumber with text 'xxx' already exists.
We understand why this error happens and how to fix it. However, running the pipeline again a lot of existing DIDs have been removed:
module.architect_ivr.genesyscloud_architect_ivr.xxx will be updated in-place
~ resource "genesyscloud_architect_ivr" "xxx" {
~ dnis = [
+ <<<600+ DIDs>>>
# (50 unchanged elements hidden)
...
That's a bit of an ugly thing because what happens is that there is a maximum number of DNIS records you can apply in a single API call. This is more than likely a problem that has existed since we implemented the chunking feature and we have not encountered it because it takes an error condition for it to occur.
We chunk the DNIS records (which means they have to be applied incrementally) to handle situations where the number of DNIS defined in a Terraform file exceeds this limit. I suspect what is happening is that the DNIS calls fail and then leave the Terraform object in an inconsistent state.
I can open a ticket on it. We might be able to add some validation in front of this to check the phone numbers before we start adding them or just discard them when an error message.
Most of my staff is out next week for the holidays so this probably won't be picked up until Jan 2nd. You might want to write a small script that checks your new numbers and makes sure they don't exist before you put them in CX as Code until we can figure something out.
Thanks,
John Carnell
Director, Developer Engagement
Thank you John. Validation prior to applying should do the trick.
As far as I remember, both "already exists" and "does not exist" (not in range) cause this so getting this handled in TF would be great as this actually causes an outage.
Charlie has the ticket right now and is investigating. I am going to chat with him at standup this morning. Hopefully, we can do some pre-validation on this. Any time we have to do "chunking" like this, it becomes problematic because Terraform is very "atomic" about things.
Thanks,
John Carnell
Director, Developer Engagement
As far as I'm aware, this problem can occur either when a phone number does not exist, or when it is already assigned to another user or IVR. Are there any other scenarios you encountered that caused this behaviour we're seeing? I just want to make sure I'm covering as many scenarios as possible when I implement a fix for this.