We hit the truncation bug described in this thread in production (iOS museum audioguide, single-speaker ~150-word French narrations, REST streamGenerateContent SSE) and ran a systematic experiment that adds a new data point: the failure pattern is not stable per voice.
Setup: same 141-word French text, all 30 prebuilt voices, gemini-3.1-flash-tts-preview, responseModalities: ["AUDIO"], one request per voice. Expected output = 55-62 s of audio.
Audit 1 (July 25, ~18:00 UTC+2):
- 15/30 completed: finishReason
STOP, 55-62 s - 15/30 truncated: finishReason
OTHER, aborted at random points between 8 s and 58 s
Audit 2 (same script, ~2 h later):
- Only 7/30 completed — and the sets flipped: Zephyr, Leda, Callirrhoe, Erinome, Laomedeia, Vindemiatrix, Gacrux, Enceladus, Algenib passed audit 1 but failed audit 2; Fenrir and Umbriel failed audit 1 but passed audit 2.
- Only Aoede completed 8/8 across the whole day (probes + audits).
Conclusions from our data:
- Truncation looks like random infra-level aborts, not a property of specific voices; failure rate varied ~50-75% depending on the hour.
- Truncated responses return HTTP 200 and the AUDIO tokens of unusable output are billed.
- Chunking to ~70 words/request reduces but does not eliminate aborts (we saw 8-24 s generations truncate too).
Our client-side mitigation (validate finishReason == STOP + duration vs word count, retry up to 3x) works but multiplies cost and latency for everyone.
Is there any update on the fix confirmed as reproduced on the other thread (June 23)? Happy to share raw measurements or run instrumented tests.