Quick question about Genesys Cloud BYOC Trunk Registration Timeout in Terraform

Voice & Telephony
1

Quick question about BYOC trunk registration stability.

  1. Defined genesyscloud_telephony_providers_edges_trunk with registration_mode = "REGISTER".
  2. Applied plan using provider version 2.25.0.
  3. Trunk shows STATUS_REGISTERED in UI but CLI returns 404 on status check.

Config snippet:

resource "genesyscloud_telephony_providers_edges_trunk" "byoc_trunk" {
 name = "Byoc-Test"
 registration_mode = "REGISTER"
 ... 
}

Is there a specific delay or retry logic missing in the provider for initial registration handshake?

2

Check your Terraform state synchronization and API retry logic. The discrepancy between the UI showing STATUS_REGISTERED and the CLI returning a 404 usually indicates a race condition in the provider’s status polling mechanism, not a fundamental failure of the BYOC trunk registration itself.

When dealing with BYOC trunks, especially in regions with higher latency, the Genesys Cloud API might report success to the UI before the underlying SIP registrar fully commits the state to the edge nodes. The Terraform provider version 2.25.0 has known quirks with genesyscloud_telephony_providers_edges_trunk where the read operation can timeout or fail to fetch the resource ID if the initial create response doesn’t immediately populate all metadata fields.

Here is a step-by-step approach to stabilize this:

  1. Increase API Timeout: Add a custom timeout to the provider configuration to allow more time for the trunk to fully register before Terraform attempts to read its state.
provider "genesyscloud" {
timeout = "120s"
}
  1. Use depends_on for Metadata: If you are attaching metadata or routing rules to this trunk in the same apply, ensure they explicitly depend on the trunk resource. This prevents concurrent write conflicts that can cause the 404 error during state refresh.
resource "genesyscloud_telephony_providers_edges_trunk" "byoc_trunk" {
# ... existing config
}

resource "genesyscloud_telephony_providers_edges_trunk_route_pattern" "example" {
depends_on = [genesyscloud_telephony_providers_edges_trunk.byoc_trunk]
# ... config
}
  1. Manual State Import: If the CLI persists with 404, the local state file might be corrupted or out of sync. Run terraform import genesyscloud_telephony_providers_edges_trunk.byoc_trunk <trunk_id> using the ID visible in the UI. This forces Terraform to re-read the current state from Genesys Cloud, often resolving the phantom 404 error.

This usually resolves the mismatch. The 404 is rarely a true resource absence; it is typically a transient state lookup failure in the provider.

3

This seems like a classic synchronization delay. Coming from Zendesk, where ticket status updates are often immediate, the asynchronous nature of Genesys Cloud telephony resources can be jarring. The UI renders the final state faster than the Terraform provider’s polling loop expects.

Instead of relying on the default status check, try adding a depends_on or a time_sleep resource to force a delay before the next resource that relies on this trunk. It is not elegant, but it works for beginners navigating the API latency.

resource "time_sleep" "wait_for_trunk" {
 create_duration = "10s"
 depends_on = [genesyscloud_telephony_providers_edges_trunk.byoc_trunk]
}

Also, ensure your provider block includes retry_wait_min = 30 to handle transient 404s gracefully. This mimics the retry logic we often had to build manually for Zendesk API migrations. The trunk is likely fine; it is just the tooling playing catch-up.