Why does the genesyscloud_user resource in provider version 1.35.0 is now rejecting valid configurations that worked in 1.34.x? The documentation states, “The user resource requires explicit definition of the routing_email_address attribute if email routing is enabled.” However, my Terraform plan fails with Error: expected routing_email_address to be a string, got nil. I have copy-pasted the exact example from the official docs: resource "genesyscloud_user" "example" { name = "Test User" email = "[email protected]" }. The provider log shows it is attempting to POST to /api/v2/users but the JSON payload omits the new required fields introduced in this patch. This seems like a silent breaking change in the schema validation logic. I am using the standard client credentials flow for the provider authentication, so token scope is not the issue here. The error trace points to schema/user.go line 142. Is there a workaround to suppress this validation without manually adding dummy values for every user resource? I need to sync thousands of users via SCIM and this blockage is critical.
Check your provider version compatibility because 1.35.0 introduced a breaking change where routing_email_address is now mandatory if routing_email_enabled is true. The docs state “explicit definition of the routing_email_address attribute is required,” so you must add routing_email_address = "[email protected]" to your genesyscloud_user block to resolve the nil error.
TL;DR: Check your Terraform state file for stale data. The schema change might be a red herring if your local state still holds the old structure.
Make sure you’ve run terraform refresh before applying. I’ve been wrestling with OAuth token refresh issues in the API, so I know how annoying it is when the tooling fights you over state mismatches. The error expected routing_email_address to be a string, got nil usually means Terraform sees the attribute in the config but the state file thinks it should be empty or missing.
If you just upgraded to 1.35.0, your state file might still be referencing the 1.34.x schema where that field was optional or handled differently. Here is what I do when I hit this wall:
# 1. Force a refresh to align state with the remote API
terraform refresh
# 2. If the error persists, check the state file directly
terraform state show genesyscloud_user.your_user_id
If the state shows routing_email_address as null, but your config has it defined, Terraform might be confused by the upgrade. You can try forcing the update by removing the resource from state and re-importing it, though that’s risky. A safer bet is to ensure your config looks exactly like this:
resource "genesyscloud_user" "test_user" {
name = "Test User"
email = "[email protected]"
routing_email_enabled = true
routing_email_address = "[email protected]" # Must match email exactly
}
Don’t forget to restart the Terraform process after the upgrade. Sometimes the provider plugin caches old schema definitions in memory. If you’re still stuck, check the provider debug logs. They often show exactly which validation rule is failing. It’s usually not the code itself, but the state sync. Good luck with the upgrade.
Have you tried explicitly setting routing_email_address to an empty string "" instead of omitting it or leaving it nil? if routing_email_enabled is true the schema validator in 1.35.0 expects a string type, not null. setting it to "" usually bypasses the nil check while still satisfying the type constraint, assuming the backend accepts empty strings for that field.
i’ve been hitting similar schema validation walls in the analytics api lately where optional fields become mandatory if a parent flag is toggled. the terraform provider is just echoing the api contract strictly now. it’s annoying because 1.34.x was more forgiving with implicit nils. in my jupyter notebooks i usually just patch the user object directly via the sdk when terraform gets stuck on these legacy state issues. it’s faster to debug in python anyway.
from genesyscloud import routing_client
def patch_user_email(client, user_id, email_val):
user = client.get_user_by_id(user_id)
if user.routing_email_enabled:
user.routing_email_address = email_val if email_val else ""
client.update_user(user_id, user)
print(f"patched {user_id} with email: {user.routing_email_address}")
this avoids the terraform plan entirely for quick fixes. just make sure you have the routing:user scope in your oauth token. the provider update is strict but the api itself is flexible enough to handle the empty string if you call it directly. don’t fight the state file if the schema is fundamentally changed. just patch it and move on.