Screen Recording session drops on GetRESTProxy 429 with null recording_id

General Discussion
1

Running into a weird bug with screen recording where the session drops hard right after a GetRESTProxy call hits a 429 in Studio. flow has the error trap sub-script wired up, but metadata just shows status: terminated and a null recording_id instead of the expected error payload. seen this twice today on prod-asia-sg with studio build 24.11.1, and the retry logic doesn’t fire because the recording is already gone.

thanks for the help.

2

Make sure you’re not relying on the standard retry logic for this. the 429 on GetRESTProxy kills the recording context before the error trap even sees it. it’s a platform-side race condition, not your flow.

try wrapping the call in a local try-catch block within the custom action instead. that way you can catch the rate limit before the session state gets clobbered by the backend.

try { await client.platformClient.rest.getRestProxy(url); } catch(e) { /* handle locally */ }

this bypasses the broken error propagation path entirely. works for me in asia-pac.

3

Have you tried adjusting the rate limit handling in your Workato recipe instead of patching the Studio flow? The 429 usually hits because the iPaaS connector fires requests faster than the Genesys Cloud API allows, especially if you’re polling for recording status. In Workato, you can add a “Pause” step or configure the Genesys Cloud connector’s retry policy to back off exponentially. This keeps the session alive while the API cools down.

steps:
 - pause:
 duration: 5s
 unit: seconds
 - genesys_cloud:
 operation: get_recording
 recording_id: "{{ trigger.recording_id }}"

This prevents the context from dropping before the error trap can catch it. i’ve seen this exact issue in multi-org setups where the global rate limit is shared. just slow down the request rate on the integration side.

4

the issue is that the recording context gets killed before the error trap can catch it. The point above is correct about the race condition.

i’m just building flows, so i don’t use custom actions or workato. for a standard flow, you need to handle the 429 differently. don’t let the GetRESTProxy block fail hard.

add a ‘Try’ block around the GetRESTProxy element. in the ‘Catch’ block, check the error code. if it’s 429, use a ‘Wait’ block (maybe 2-3 seconds) and then loop back to the Try block. this gives the API a breather.

also, make sure you aren’t polling too fast. if you’re checking status every second, the 429 will hit. space it out.

the null recording_id happens because the session state is already gone when the trap runs. catching it locally in the flow keeps the context alive.