- Platform: Genesys Cloud (EU-West-1 region)
- Feature: Bulk Recording Export via API
- Channel: WebRTC Softphone (Voice)
- API Endpoint: POST /api/v2/architect/flows/export (triggering recording metadata fetch)
- SDK/Client: Python requests library, custom wrapper for bulk jobs
- Error: HTTP 504 Gateway Timeout after 120s
- Frequency: Intermittent, ~15% of jobs initiated during business hours (09:00-17:00 GMT)
The specific issue relates to bulk export jobs targeting WebRTC softphone interactions for legal discovery. While PSTN and SIP trunk recordings export successfully via the standard /api/v2/recording/bulk endpoint, jobs filtering for channel: webrtc frequently fail with a 504 Gateway Timeout. The job status remains IN_PROGRESS for exactly 120 seconds before the timeout occurs. No error code is returned in the final job status payload, only the timeout indication from the gateway layer.
Investigation into the request headers shows that the X-Genesys-Trace-Id is present, but correlating this with the internal logs (via support ticket #GCS-99281) reveals that the metadata aggregation service hangs when attempting to resolve the sessionId for WebRTC streams that were terminated abruptly (e.g., network drop). The chain of custody requirement for our legal team mandates that every interaction, including dropped calls, must have an associated metadata record for audit trails.
The current workaround involves splitting the export date range into 1-hour chunks, which reduces the timeout rate to <2%, but this is not sustainable for large-scale discovery requests involving millions of interactions. We have verified that the S3 destination permissions are correct and that the service account has recording:export and architect:read scopes. The problem seems isolated to the metadata resolution step for WebRTC sessions, not the audio file transfer itself, as the audio files are often available in S3 even if the bulk job fails.
Has anyone encountered this specific latency issue with WebRTC metadata aggregation during bulk exports? Is there a known limit on the number of WebRTC sessionId lookups that can be processed in a single bulk job request? We need a reliable method to export these records without manual chunking to maintain an unbroken audit trail for compliance.