Just noticed that our automated bulk export jobs for WhatsApp voice and text transcripts are getting stuck in a QUEUED state indefinitely when specific legal hold metadata fields are requested. This is causing significant delays in our chain of custody documentation for ongoing litigation matters.
The environment is Genesys Cloud EU-West-1. We are using the Python SDK v2.16.2 to trigger these exports via the POST /api/v2/recordings/jobs endpoint. The issue appears specifically when we include the legal_hold_reason and custodian_id fields in the metadata array of the export request body. Without these fields, the job completes successfully and the files land in our S3 bucket within the expected SLA window.
Here is the relevant snippet from our request payload:
{
"name": "Legal_Hold_Export_WA_202310",
"recordingsType": "WHATSAPP",
"metadata": [
"legal_hold_reason",
"custodian_id",
"interaction_id"
],
"filter": {
"query": "timestamp:[2023-10-01T00:00:00Z TO 2023-10-02T00:00:00Z]"
}
}
The job ID is generated, and the status remains QUEUED for over 24 hours. No error message is returned in the job status response, just a persistent lack of progression to RUNNING or COMPLETE. The S3 bucket permissions are verified and correct, as other jobs without the specific legal metadata succeed.
Is there a known limitation or bug with the WHATSAPP recording type when filtering or exporting custom legal metadata? We need to ensure the integrity of the audit trail, so we cannot simply drop these fields. Any insights on why the queue is blocking this specific configuration would be appreciated. We are checking the job logs via the API, but they provide limited detail on the internal processing failure.