looking for advice on a persistent discrepancy between the recording metadata returned by the /api/v2/architect/flows/{flowId} endpoint and the actual files delivered via the bulk export s3 integration. we are running genesys cloud eu-west-1 with version 2024-02.15. the issue specifically impacts outbound dialing campaigns using the predictive dialer mode.
when initiating a bulk export job for recordings tagged with legal_hold:true, the job completes successfully. however, upon inspection of the downloaded csv manifest and the corresponding mp3 files, the recording_id in the manifest does not match the filename prefix in s3. furthermore, the start_time and end_time fields in the manifest are utc, but the actual audio duration suggests a timezone offset of gmt+0, which should be consistent.
the api response for the flow shows the recording action is configured to capture both agent and customer streams. yet, the bulk export only delivers the customer stream for calls where the disposition is set to abandoned. this breaks our chain of custody requirements for legal discovery, as we cannot prove the agent did not speak before the hangup.
we have verified the s3 bucket policy allows full access to the export service. the error log in the bulk export dashboard shows no failures, only warnings about metadata_processing_delay. is this a known limitation of the outbound recording pipeline when handling high-volume abandoned calls? or is there a specific configuration in the recording action within the architect flow that forces stream separation before the export job runs?
we need the agent stream for these abandoned calls to satisfy compliance audits. any insights into why the bulk export service might be filtering these streams based on disposition would be appreciated. we are currently working around this by manually fetching each recording via the api, but that is not scalable for the 10,000+ recordings involved in this request.