Is it possible to force a clean reconciliation of genesyscloud_routing_prediction resources when the API returns inconsistent state hashes? We are seeing persistent drift in our AU-1 BYOC environment during nightly CI/CD runs. The Terraform plan identifies no changes, yet the subsequent CLI push operation fails with a 409 Conflict. This occurs specifically when updating the strategy_id to point to a new Architect flow version. The payload matches the current API response exactly, but the server rejects the update citing a version mismatch on the underlying strategy object.
The environment uses Genesys Cloud CLI v2.1.0 and Terraform provider v1.5.8. Our GitHub Actions workflow executes a standard genesyscloud push command after a successful terraform apply. The error log indicates that the strategy_id in the request body does not align with the internal state managed by the Predictive Routing engine. We have verified that the Architect flow is published and active. The strategy_id is valid and resolves correctly via GET /api/v2/routing/predictions. However, the PUT request to update the strategy fails silently in some cases or returns a conflict in others.
We attempted to bypass this by adding a depends_on block for the Architect flow resource and using a post_deploy script to fetch the latest strategy version via the REST API. This adds unnecessary complexity to the pipeline. The core issue appears to be a race condition or a caching layer in the AU-1 region that does not reflect the immediate state of the Predictive Routing configuration. The CLI tool seems to rely on a stale cache of the strategy metadata.
Looking for insights on how to handle this drift without manual intervention. Is there a specific flag in the CLI or a retry mechanism in the Terraform provider that can handle these transient 409 errors? We need a robust way to ensure our predictive routing strategies are updated atomically with our Architect flows. Any examples of handling this specific conflict in a BYOC setup would be appreciated. The current workaround involves restarting the workflow, which is not scalable for our deployment frequency.