Stumbled on a weird bug today with the screen recording endpoint when scaling up JMeter threads. I am trying to validate the throughput of the POST /api/v2/recordings/screen endpoint in the Singapore region (us-east-1 is the default but we are routing through ap-southeast-1 via our internal proxy). The goal is to see how the API handles concurrent upload requests from simulated agents.
I have a JMeter script that simulates 100 concurrent users, each attempting to upload a small 5MB screen recording file every 30 seconds. Initially, everything works fine. The first 20 threads get a 201 Created response with the expected recording ID. However, as soon as I ramp up to 50 threads, I start seeing intermittent 502 Bad Gateway errors. These are not consistent; some requests succeed while others fail with the same payload.
Here is the relevant part of my JMeter HTTP Request sampler:
POST /api/v2/recordings/screen
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Authorization: Bearer {{access_token}}
The error response body is empty, just a 502 status code. I am using the Genesys Cloud Java SDK v4.0.1 for authentication and token management, but the actual upload is done via raw HTTP in JMeter to bypass any SDK overhead. I have checked the API rate limits, and I am well within the documented limits for screen recordings. The WebSocket connection for the actual screen capture is stable, and the files are generated locally before upload.
I suspect this might be related to how the API handles concurrent multipart uploads or perhaps a temporary spike in load on the recording service. Has anyone else seen this behavior with high concurrency on the screen recording API? I am looking for any insights on whether this is a known limitation or if I need to adjust my JMeter configuration, such as adding delays or reducing the concurrency level. Any help would be appreciated.