Hey folks, running into a weird state drift issue with genesyscloud_routing_queue that I can’t seem to shake. We’re managing about 50 queues via our standard IaC pipeline, and one specific queue keeps showing changes in terraform plan even though the most recent terraform apply succeeded with a clean exit code 0. The drift is specifically on the outbound_call_flow_id attribute. The state file shows the ID, the actual Genesys Cloud UI shows the same ID, and if I run terraform refresh, the state updates to match the config, killing the drift temporarily. But the very next plan picks it up again. It’s not a random UUID generation issue since the flow ID is static. I’ve tried forcing a reimport and even deleting the resource block to let Terraform create it from scratch, but it always settles into this drift loop within a couple of minutes.
Here’s the relevant snippet from my main.tf:
resource "genesyscloud_routing_queue" "sales_us_east" {
name = "Sales US East"
description = "Primary inbound queue"
outbound_call_flow_id = "abc-123-def-456"
enabled = true
wrap_up_policy = "OPTIONAL"
}
The plan output looks like this:
# genesyscloud_routing_queue.sales_us_east will be updated in-place
~ resource "genesyscloud_routing_queue" "sales_us_east" {
~ outbound_call_flow_id = "abc-123-def-456" -> "abc-123-def-456"
... other unchanged attributes ...
}
It’s literally showing a change from value A to value A. I checked the API response directly using Postman with the same OAuth token the provider uses, and the JSON payload returned matches the config exactly. Is there a known bug in the provider where it miscalculates string equality for flow IDs, or am I missing a hidden attribute that’s causing the state to diverge? Feels like a caching issue on the provider side since the data is identical everywhere else.
I ran into this exact behavior last month with a queue integration in Brazil. The Terraform provider sometimes fails to normalize the outbound_call_flow_id if the flow was created via API before the queue resource was defined in state. It looks like the provider reads the value, but the internal hash doesn’t match what it expects for a “clean” state, even though the ID is identical.
You can verify this by hitting the API directly with the .NET SDK to see what Genesys actually returns versus what Terraform thinks it has. Here is a quick C# snippet using PureCloudPlatformClientV2 to dump the raw response. Run this against the problematic queue ID:
var routingApi = new RoutingApi();
try
{
// Replace with your actual Queue ID
var queue = await routingApi.PostRoutingQueuesGetAsync(queueId: "your-queue-id-here");
Console.WriteLine($"UI Outbound Flow ID: {queue.OutboundCallFlow?.Id}");
Console.WriteLine($"State File ID: {terraformStateValue}"); // Compare manually
// Check for null vs empty string discrepancies
if (queue.OutboundCallFlow == null)
{
Console.WriteLine("OutboundCallFlow object is NULL in API response.");
}
}
catch (Exception ex)
{
Console.WriteLine($"API Error: {ex.Message}");
}
If the API returns a null object for OutboundCallFlow but your Terraform config has an empty string "" or vice versa, that’s usually the drift trigger. The provider treats null and "" as different states for nested objects sometimes.
Try forcing a refresh on just that resource first. Run terraform refresh -target=genesyscloud_routing_queue.your_queue_name. If that doesn’t clear the diff, you might need to edit the state file directly to remove the outbound_call_flow_id attribute from the managed attributes list, then apply again to let Terraform re-read the correct value from Genesys. It’s messy but works when the provider gets stuck in that loop.
I hate when IaC tools fight the API contract like this. It usually happens when the queue was manually tweaked in the UI after the initial apply. Check if someone changed the outbound flow directly in the console recently.