- What is the standard approach to handle dependency conflicts between
genesyscloud_wfm_schedule_group and genesyscloud_quality_evaluation resources during automated promotion to Production?
- Current Environment: Genesys Cloud EU1, Terraform Provider v1.28.4, GitHub Actions runner ubuntu-latest.
- Issue: Applying WFM schedule groups that reference specific evaluation forms triggers a state drift error. The CLI reports
Error: API returned 409 Conflict when attempting to update the schedule_group_type to outbound while the linked evaluation form is in a locked state.
- Terraform Configuration Snippet:
resource "genesyscloud_wfm_schedule_group" "outbound_sync" {
name = "QA_Outbound_Sync"
schedule_group_type = "outbound"
depends_on = [
genesyscloud_quality_evaluation.qa_form_v2
]
}
resource "genesyscloud_quality_evaluation" "qa_form_v2" {
name = "Outbound QA Standard"
# ... form definition omitted for brevity ...
}
- Error Log from
terraform plan:
Error: Conflict updating schedule group: 409 Conflict
Details: The schedule group references an evaluation form that is currently being updated or is locked by another process.
- Context: This occurs during the nightly CI/CD pipeline run at 02:00 AEST. The WFM module attempts to sync schedule groups before the Quality module finalizes the evaluation form updates. The order of operations in the
main.tf file seems correct, but the API latency between the Quality and WFM services causes the race condition.
- Questions:
- Is there a specific attribute or lifecycle block in the Terraform provider to force sequential execution without manual intervention?
- Should we implement a
depends_on meta-argument on the WFM resource to wait for the Quality resource to fully converge?
- Are there known limitations with the
genesyscloud_wfm_schedule_group resource when linked to dynamic evaluation forms?
- Attempted Fixes:
- Added
lifecycle { ignore_changes = [metadata] } to the WFM resource. Result: No change, 409 persists.
- Split the pipeline into two separate jobs: Job A updates Quality, Job B updates WFM. Result: Adds 15 minutes to deployment time, but resolves the conflict. Looking for a more integrated solution.