WebRTC Recording Metadata Mismatch in Bulk Export for Legal Discovery (Genesys Cloud v2024.02)

Facing a data integrity issue with WebRTC softphone recordings during bulk export jobs for legal discovery requests. The environment is Genesys Cloud v2024.02, London region. The specific problem involves the conversation_id field in the exported metadata JSON not matching the actual recording file hash when retrieved via the /v2/recordings/recordings/{recordingId} endpoint.

We are exporting records for a specific date range using the bulk export API. The chain of custody requires exact matching between the manifest file and the S3 objects. However, for WebRTC recordings, the metadata payload shows a status of completed but the media_urls are null or pointing to expired pre-signed URLs that have already rotated.

{
 "recording_id": "rec_web_12345",
 "media_urls": null,
 "status": "completed",
 "type": "web-rtc"
}

Is this a known latency issue with the metadata propagation for WebRTC media in the London region? The PSTN recordings export without this discrepancy. Need to ensure the audit trail remains unbroken for the legal hold. Any insight on the correct sequence to validate these URLs before finalizing the export job?