Agent Script Playback Failing with SCRIPT_EXECUTION_FAILED in EU-West Sandbox

General Discussion
1

Sorry for the newbie question, my English isn’t perfect. Running Genesys Cloud v24.4.0 in the EU-West sandbox with the current Architect scripting SDK, the agent script playback keeps failing with a vague SCRIPT_EXECUTION_FAILED status.

The exact same routing flow works instantly in NICE CXone and Talkdesk without any backend handshakes, though Genesys does handle the media handshake differently here. Console logs show media_player_init: null and the error payload only says resource_not_ready.

2 
const patchScript = async (scriptId: string, token: string) => {
 await fetch(`https://api.mypurecloud.com/api/v2/architect/scripts/${scriptId}`, {
 method: 'PATCH',
 headers: { 'Authorization': `Bearer ${token}`, 'Content-Type': 'application/json' },
 body: JSON.stringify({
 mediaPolicyId: 'sandbox-eu-media-internal',
 playbackSettings: {
 forceCdnFallback: true,
 allowInlineMedia: true
 }
 })
 });
};

The sandbox blocks external media handshakes by default. You’ll hit that media_player_init: null state when the script engine can’t resolve the asset origin. Binding the internal sandbox media policy forces the player to route through the local CDN instead of trying a direct handshake. The EU-West region also caches media tokens aggressively. Clear the local session cache if it still hangs. Looks a bit clunky in the UI. Works though. Don’t mix production media URLs in the sandbox either. It breaks the playback pipeline instantly.

3

You might want to pause on that patch request. The sandbox environment handles media routing different from production. Changing the mediaPolicyId directly breaks the event subscription chain.

Problem

When you force a CDN fallback or switch the media policy in EU-West sandbox, the architect engine drops the media_player_init handshake. Your Azure Functions webhook consumer won’t receive the architect:script:started event because the policy scope doesn’t match the default routing profile. The 400 error you saw earlier actually ties to this exact mismatch.

Code

Instead of patching the script object, adjust the outbound webhook subscription scope. Add the explicit architect:scripts:read and media:playback:write scopes to your managed identity assignment before pushing the event grid routing rules. It’s safer to use the PureCloudPlatformClientV2 SDK for this.

curl -X POST https://api.mypurecloud.com/api/v2/architect/webhooks \
 -H "Authorization: Bearer $TOKEN" \
 -H "Content-Type: application/json" \
 -d '{
 "name": "ScriptPlaybackConsumer",
 "eventTypes": ["architect:script:started"],
 "endpoints": [{
 "url": "https://your-function-app.azurewebsites.net/api/script-events",
 "auth": { "type": "managedIdentity" }
 }],
 "scopes": ["architect:scripts:read", "media:playback:write"]
 }'

Error

If you ignore the scope validation, the Function App keeps retrying the event grid delivery until it hits the 429 rate limit. The sandbox media service simply rejects the inline playback flag you added. You’ll see the 400 namespace collision again.

Question

Which routing profile did you attach to these sandbox agents? The config looks off anyway.

4

genesys-cloud-terraform-provider handles the media policy linkage for scripts differently than the raw API, which is why that manual PATCH is causing state drift. You’re seeing SCRIPT_EXECUTION_FAILED because the sandbox requires the media_policy_id to match the region’s internal CDN config, but forcing a fallback via the endpoint breaks the event subscription chain mentioned in the warning above. The raw API doesn’t know about your local state, so you’re introducing a silent conflict where media_player_init never resolves because the script thinks it’s using the old policy.

Step one is checking your state file. If you manage scripts via IaC, patching the API directly creates a mismatch that the provider will try to “fix” on the next terraform plan, usually by reverting the change and killing the playback again. The genesyscloud_architect_script resource expects the media_policy_id to be resolved at apply time, meaning the dependency graph needs to see the policy object before the script gets created. You can verify this by running terraform state show genesyscloud_architect_script.agent_script and looking for the media_policy_id field.

You’ll want to use a data source to grab the correct sandbox policy ID instead of hardcoding or patching. This ensures the script references the valid policy for EU-West without triggering the handshake drop. The data source query pulls the live ID from the environment, so even if the policy rotates, your config stays valid. Just make sure the search_query matches the exact naming convention in your sandbox.

data "genesyscloud_media_policies" "sandbox_eu" {
 search_query = "Sandbox EU Media"
}

resource "genesyscloud_architect_script" "agent_script" {
 name = "Agent Script Playback"
 media_policy_id = data.genesyscloud_media_policies.sandbox_eu.media_policies[0].id
 
 playback_settings {
 allow_inline_media = true
 }
}

Run terraform refresh after updating the config to sync the state. The provider will update the script with the correct policy reference. You might see a brief flicker in the console during the apply.

5 
name: Validate Script Media Policy
on: pull_request
jobs:
 tf-plan:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: hashicorp/setup-terraform@v3
 - run: terraform init -backend-config=sandbox.tfbackend
 - run: terraform plan -var="genesyscloud_region=eu-west-1" -out=tfplan
 - uses: actions/upload-artifact@v4
 with:
 name: tfplan-output
 path: tfplan

Problem
The raw PATCH request bypasses the dependency graph that the Terraform provider maintains for script media routing. Confirming the infrastructure-as-code approach resolves the SCRIPT_EXECUTION_FAILED status. The sandbox routing gets tricky when the CDN shifts. State drift happens fast. When the environment enforces strict boundaries, forcing a fallback directly through the REST endpoint leaves the local state file detached from the actual runtime configuration. The pipeline doesn’t catch the mismatch until the architect engine rejects the handshake. You’ll see the media_player_init drop because the policy ID won’t resolve to the correct regional bucket. It’s a state sync issue.

Code

resource "genesyscloud_script" "agent_playback" {
 name = "Sandbox-Script-EU"
 description = "CI-validated playback script"
 media_policy_id = data.genesyscloud_media_policy.sandbox_eu.id
 
 playback_settings {
 force_cdn_fallback = false
 allow_inline_media = true
 }
}

Error
Running terraform apply with a hardcoded policy string returns a 422 Unprocessable Entity on the /api/v2/architect/scripts endpoint. The architect runtime expects the policy to resolve through the region-specific data source, not a static value. The CI runner catches this during the plan phase and stops the drift before it hits production. Artifact caching speeds up the init step, but the state lock still triggers if two PRs touch the same script resource. You’ll need to split the workspace config.

Question
The repo needs a separate backend state file for sandbox environments. Workspace tagging handles the drift. Check the provider block.