Terraform apply throws 409 Conflict on genesyscloud_auth_division during initial state push

Trying to spin up a fresh reporting environment for the dashboard aggregator. Ran terraform apply on the provider config and it keeps choking on the division resource. The state file shows the entity is already tracked but the platform API keeps rejecting the create call with a 409 Conflict.

The resource block looks standard enough. resource "genesyscloud_auth_division" "analytics_div" { name = "reporting-analytics" description = "Division for custom dashboard metrics" enabled = true }

The CLI output dumps { "code": 409, "message": "Conflict", "status": "Conflict" } right after the initial handshake. I’ve checked the /api/v2/users/me/divisions endpoint manually and the name isn’t taken. State refresh doesn’t fix it either. Running terraform state pull shows the resource ID is null, which means the POST /api/v2/admin/divisions call never actually succeeded.

Not sure if the provider is retrying the same payload or if there’s a race condition with the default division creation. We’ve been using the genesyscloud provider v1.60.4 and the auth flow is client_credentials. The token scope includes division:read and division:write. Maybe the externalId field needs to be set explicitly to bypass the conflict check. Or is the platform caching the request hash? The genesyscloud_auth_division resource seems to ignore the lifecycle { ignore_changes = [name] } block when the state is empty. The terraform plan diff shows a create action but the actual HTTP trace logs a 409 immediately. I’ve tried adding depends_on to the queue resource but the provider still fires the division request first. The retry logic in the provider keeps hammering the same endpoint. Debug logs show the payload hash matches the previous attempt.

Any idea how to force the provider to skip the duplicate name check or attach a unique suffix automatically? The dashboard pipeline halts right there. Need to push the state forward.