TF Error with schedules

Genesys Cloud Integrations
1

Hello,

We are experiencing another issue with schedules under provider 1.40.0.

Adding an object:

module.architect_schedules.genesyscloud_architect_schedules.mo-fri_0800-2000 will be created

  • resource "genesyscloud_architect_schedules" "mo-fri_0800-2000" {
    • description = "Mo-Fri-0800-2000"
    • division_id = "xxx"
    • end = "2022-02-05T20:00:00.000000"
    • id = (known after apply)
    • name = "Mo-Fri_0800-2000"
    • rrule = "FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR"
    • start = "2022-02-05T08:00:00.000000"
      }

During deployment:

  • This message is displayed for 5 minutes: 2024-07-10T19:07:05.3987918Z module.architect_schedules.genesyscloud_architect_schedules.mo-fri_0800-2000: Still creating... [5m0s elapsed]
  • TF fails with the following:

...
2024-07-10T19:07:05.4813688Z Error: mismatch on attribute start:
2024-07-10T19:07:05.4816251Z expected value: 2022-02-05T08:00:00.000000
2024-07-10T19:07:05.4817148Z actual value: 2022-02-07T08:00:00.000000
2024-07-10T19:07:05.4817426Z
2024-07-10T19:07:05.4818032Z with module.architect_schedules.genesyscloud_architect_schedules.mo-fri_0800-2000,
2024-07-10T19:07:05.4818755Z on modules/architect_schedules/mo-fri_0800-2000.tf line 1, in resource "genesyscloud_architect_schedules" "mo-fri_0800-2000":
2024-07-10T19:07:05.4819226Z 1: resource "genesyscloud_architect_schedules" "mo-fri_0800-2000" {
...

However, the schedule itself gets created in the system.

Could you please review and advise?

Thank you.

2

Hello again,

The only workaround for this issue we found is to adjust the start/end in TF to match what was created inside Genesys Cloud (to get rid of our failures).

However, we still don't understand why the date is wrong in GC in the first place, right after the object is created - we tried with different dates and objects, and it "seems" to be +1 to 2 days.

Additionally, even if we make the change in TF, TF still considers the object tainted and deletes/re-creates the object.

Thank you.

3

Hi @jmakacek

I will create a ticket for this and we will investigate as soon as possible. The error is being thrown from our consistency checker. If you set the env variable BYPASS_CONSISTENCY_CHECKER you can change this behaviour and have such errors written to file instead of having the program through an error. Just note though that allowing the program to continue may cause some unexpected behaviour.

Regards,
Declan

4

Hi JMakacek,

Thanks for letting us know. Usually, these types of problems occur when the Public API we call mutates the data presented to it. Then we have a situation where Terraform has stored the data in the state file than was originally presented, and the API has been stored in a slightly different format. That is probably the case here, but we wont know until we investigate further.

Thanks,
John Carnell

5

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.