We started getting the following error in 'terraform plan' when running against our architect_user_prompt objects:
Error: prompt file not transcoded
The issue is that the above is the whole error message - it does not list any file/resource and there is no indication of what could be causing this.
When it comes to our prompt Cx-As-Code objects, we do not store any language or file resources in CICD - all we store is prompt name and description. We also started getting this error without any modifications to Cx-As-Code prompts - only existing prompts, which worked without issues on Friday, but started failing on Saturday.
Our MyPureCloud client version is 1.23.0, and I also tried running it with 1.26.0 with the same result.
Weird. We will take a look. This sounds suspiciously like an underlying API changing its behavior as we have not released any new code since 1.26.0 two weeks ago and it seems to impact 1.23.0 with a sudden change overnight in behavior. I will open a ticket on our end and dig into it.
Thanks,
John Carnell
Director, Developer Engagement
Please reach out to me if you need any further details or if there's anything we can do to escalate this - as a result of this error, we lost the ability to push updates through Cx-As-Code.
For the time being it's only in our Dev Environment, but we do have pushes coming for Test and Prod and until we understand what happened, I would consider this a "major" issue.
I have located where the error message is being thrown in the code base, and it looks like it can only occur when a user prompt in your terraform config has a resource block and the field filename has some value (i.e. is not an empty string.)
To help identify which user prompt is throwing the error, you can run the following command to enable logging:
export TF_LOG=debug
Now if you run:
terraform plan &> plan.log
...you can search through the log file to find the culprit. Here is a snippet of my log file below.
2023-12-12T13:33:32.817Z [INFO] provider.terraform-provider-genesyscloud_v1.26.0: 2023/12/12 13:33:32 Reading User Prompt 99b6e9e4-13ba-xxxx-xxxx-4c5dd071ccff: timestamp=2023-12-12T13:33:32.817Z
2023-12-12T13:33:32.818Z [INFO] provider.terraform-provider-genesyscloud_v1.26.0: 2023/12/12 13:33:32 [DEBUG] Waiting for state to become: [success]: timestamp=2023-12-12T13:33:32.817Z
2023-12-12T13:33:33.176Z [INFO] provider.terraform-provider-genesyscloud_v1.26.0: 2023/12/12 13:33:33 Read Audio Prompt 99b6e9e4-13ba-xxxx-xxxx-4c5dd071ccff 99b6e9e4-13ba-xxxx-xxxx-4c5dd071ccff: timestamp=2023-12-12T13:33:33.176Z
In your case, for the user prompt that caused the error, the line "Read Audio Prompt..." would never have been reached. So you should see "Reading audio prompt " , but no "Read audio prompt..."
We are definitely going to add more detail to the error message you received, so users don't have to do all this detective work in the future. However I'm not sure yet if this is a bug within our provider, or an issue with your user prompt. We'll know better than we have more details on the prompt in your org that is causing these issues.
I searched our prompt codebase and we do not have "filename" anywhere - we do not even store "resources" objects in our prompts, we only have name and description fields.
I have also searched our pipeline logs and "Reading audio prompt" is not in the log file.
Would it please be possible to set up a call so that we can walk through this and provide any debug information we can? As mentioned earlier, we are unable to push any prompts through the pipeline at the moment.
Did some more testing - tried with "DEBUG", DEBUG, "debug", debug, etc. Tried running the exact terraform plan command from the post above. Same error and no useful entries in the log file as far as I can see.
Also tried with 1.27.0, same error message.
The only other thing I could think of is perhaps the terraform version (we are using Terraform Enterprise workspaces), but I confirmed here that we are good: Is there a recommended Terraform version to use?
Could you please advise on next steps? Should I open a Genesys Case and get a call set up to see what other option we have?
Charlie believes he found a fix that has been incorporated in version 1.28.0 of CX as Code (released earlier today). It was a subtle bug, but Charlie is confident that he has fixed it. Please give it a try and post back if it does not work. Charlie is in Ireland so he will be online early (3:00 AM) on Monday morning.
Thanks,
John Carnell
Director, Developer Engagement