Plan not performing same validations as Apply

[jmakacek]

Hello,

We were wondering whether it is possible for TF Plan to perform the same steps/checks/validations as TF Apply.

We have noticed this for other object types in the past, but the most recent example we have is with genesyscloud_flow:

Plan shows (correctly) that a flow update will be applied:

~ resource "genesyscloud_flow" "FLOW_NAME" {
+ file_content_hash = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
id = "xxxxxxxxxxxxxxxxxxxx"
# (1 unchanged attribute hidden)
}

However, during a release, when we run Apply, the flow update fails (in this case due to a missing dependency - missing column in a datatable):

...unable to find 'field xxx' on the action 'dataTableLookup' named 'yyy'

If I recall correctly, another example from past would be Apply stage fails to create object when it already exists (rightfully so), but the Plan stage only displays that it will be created.

Would it please be possible to detect these types of things as part of the Plan stage? In other words, can the Plan stage run all the same validations as the Apply stage?

Thank you in advance.

[jmakacek]

Hello,

Apologies for replying to myself, I have a few more examples.

Datatable update - Plan indicates columns will be removed. Apply:
...API Error: 400 - Field '[REDACTED len=28]' is missing from the proposed schema...

DNC List Division update - Plan indicates Division will be changed. Apply:
...
Error: mismatch on attribute division_id:
expected value: xxxxxxx
actual value: yyyyyyy
...

Prompt removal - Plan indicates prompt will be removed. Apply:
...
Error: Failed to delete user prompt PROMPT_NAME: API Error: 409 - 'PROMPT_NAME' cannot be deleted because other objects depend on it.
...

Thank you.

[jmakacek]

Hello,

We had another example with Callabletimeset:
...
Error: Failed to delete Outbound Callabletimeset: Failed to delete timeset: API Error: 400 - Referential integrity is not satisfied
...

Thank you.

[Rohit.Sharma3]

We have few more instances where similar behavior is seen:

1. Plan indicates architect_ivr dnis list will be updated, apply fails:

{"resourceName":"genesyscloud_architect_ivr","method":"PUT","path:omitempty":"/api/v2/architect/ivrs/xxxx-id","statusCode:omitempty":400,"errorMessage":"API
Error: 400 - Field 'didPoolId' is required and cannot be empty.
(xxxx-id)","correlationId":"xxxx-id"}

2. Plan indicates architect_datatable column will be updated, but then fails during apply:

Error: Failed to update architect_datatable XX-DT Overrides: API Error: 400 - Field '[REDACTED len=28]' is missing from the proposed schema (xxxx-id)

3. Plan indicates responsemanagement_response will be added, apply fails:

Error: failed to create Responsemanagement Response XXXX-RSM-Name: API Error: 400 - The library, xxxx-id, already has a maximum of 200 responses (xxxx-id)

Regards,
Rohit

[John_Carnell]

Hi JMakacek,

The plan is a purely Terraform function where it Terraform checking the state of the object in its state file against the target cloud system. There is no validation mechanism for us to hook into. All it is doing is a read against Genesys Cloud to retrieve the record and determine if there is the record is there or not. I can take this back to me team, but I don't think there is anything we can do out of the box to avoid these type of errors.

Thanks,
John Carnell
Director, Developer Engagement

[John_Carnell]

@Rohit.Sharma3

1. y fails:

{"resourceName":"genesyscloud_architect_ivr","method":"PUT","path:omitempty":"/api/v2/architect/ivrs/xxxx-id","statusCode:omitempty":400,"errorMessage":"API
Error: 400 - Field 'didPoolId' is required and cannot be empty.
(xxxx-id)","correlationId":"xxxx-id"}

2. Plan indicates architect_datatable column will be updated, but then fails during apply:

Error: Failed to update architect_datatable XX-DT Overrides: API Error: 400 - Field '[REDACTED len=28]' is missing from the proposed schema (xxxx-id)

3. Plan indicates responsemanagement_response will be added, apply fails:

Hi Rohit,

These are not plan issues. Per my comment to JMacek, a Terraform plan checks the state of the object in its backing state with the state of the object in Genesys Cloud. If the object is different (e.g. has been changed, does not exist, etc...) Terraform will then try to take the appropriate action.

1. In your first error message you are trying to apply a change that is missing the didPoolId in the genesyscloud_architect_ivr resource that you are trying to apply.

2. In the second message, you are trying to go beyond the total number of responses allowed and it will fail on the apply. From a plan perspective, it appears to be legit because Terraform is only checking the values in the Terraform backing state and the record residing in Genesys Cloud.

Thanks,
John Carnell
Director, Developer Engagement

[jmakacek]

Thank you for checking - we were hoping something could be done as our pipeline runtimes are pretty long due to the number of objects, so we were hoping we could avoid some of the re-runs in cases like these.

Best Regards,
Juraj