the request reached your backend, but synchronous processing took too long for the edge/proxy path
Observed deployment behavior:
public HTTPS can time out even when the same request path is valid and the backend is healthy
observed hosted sample timings:
~17.2 MB MP4: ~26s
~38.6 MB MP4: ~26-37s
~59.2 MB MP4: ~32-34s backend completion, but some browser requests still timed out first
Guardrail:
use fast mode for smaller, interactive files
use batch mode for large uploads or longer media where waiting synchronously through the web UI is brittle
add request-level logging for:
file name
file size
mime type
upstream elapsed time
response payload size and top-level keys
so you can tell whether the origin completed successfully while the browser/edge timed out
for hosted UIs, wrap fast mode in an async request/polling flow instead of holding the browser open for the entire upstream response
if nginx access logs show 499 while app logs later show zoom_request_finished status: 200, the transcription succeeded and only the browser-side request path was lost
the browser emitted a valid first container chunk, but later MediaRecorder timeslice blobs were partial WebM/Opus clusters without fresh container headers
Symptoms:
chunk 1 transcribes normally
chunk 2 onward returns empty transcript text or much weaker results
auth and request flow still look healthy
Preferred fix:
do not rely on one long MediaRecorder.start(timeslice) session for standalone chunk uploads
rotate the recorder per chunk instead:
start recorder
record one chunk window
stop recorder
upload that blob
start a new recorder for the next chunk
Guardrail:
treat browser microphone pseudo-streaming as a file-container problem first, not a Scribe-language-model problem