Update after six more nightly measurements — this has gotten significantly worse, and it
is no longer just the missing GoAway.
1. The idle lifetime is collapsing. Same automated probe as in the original post
(code unchanged since Jul 25; open a session on gemini-3.1-flash-live-preview, stay
idle, measure time to termination and whether GoAway precedes it):
Aug 1: GoAway after 540.3 s, timeLeft "50s", clean close
Aug 2: GoAway after 540.3 s, clean close
Aug 3: GoAway after 540.3 s, clean close
Aug 4: hard close 1006 (empty reason) after 533.1 s — no GoAway
Aug 5: 1006 after 523.1 s — no GoAway
Aug 6: 1006 after 480.6 s — no GoAway
Aug 7: 1006 after 391.4 s — no GoAway
Aug 8: 1006 after 309.5 s — no GoAway
Aug 9: 1006 after 253.1 s — no GoAway
Aug 10: 1006 after 191.6 s — no GoAway
Through Aug 3 the lifetime was deterministic to the second (540.3 s three nights in a
row). Since Aug 4 the warning is gone and the idle lifetime has fallen from ~9 minutes
to ~3.2 minutes within one week, shrinking almost monotonically by ~60–90 s per day.
2. Active sessions show a second face of the problem — response-plane stalls on an
OPEN socket. Across nine real sessions on Aug 10 (continuous audio streaming, so idle
timeouts on the network path do not apply), our client detected five silent response
stalls in four sessions (four unambiguous, one with a possible VAD confound), at
session ages of 65.5, 82.1, ~89.5, 153.7 and 497.9 seconds. In every case the WebSocket
remained OPEN and the server kept delivering sessionResumption handle updates at ~1/s
throughout the silence window — only the response plane went quiet. No GoAway, no close
frame. Our response watchdog (~7 s) then tore the session down; the resume reconnect
opened a fresh socket in 150–200 ms and recovered with context intact, proving the
network path was healthy. Each stall costs the user roughly eight seconds of “the
assistant stopped responding”. Independent corroboration from another user:
WebSocket ping timeout after ~170 seconds on the same model (2.5 Live worked fine).
Impact: This is a production voice application with long-running conversations.
Without GoAway the documented graceful-handover pattern is impossible; with idle
lifetimes collapsing and active sessions stalling at unpredictable moments, users hit
multi-second freezes several times per conversation. And with the earlier Live
generations retired or scheduled for retirement, gemini-3.1-flash-live-preview is
effectively the only Live API path going forward — currently degrading week over week.
Open questions, more urgent than a week ago:
- Was there a server-side change around Aug 3/4 affecting GoAway delivery for
gemini-3.1-flash-live-preview — and is it a known incident? - Is GoAway still a guaranteed part of the connection-termination contract, or should
clients now treat silent connection death as expected? - Are the shrinking idle lifetime and the mid-conversation response stalls intentional
(quota/abuse control?) or part of the same regression? - Possibly related to the ongoing investigation in
this thread (1011 / resumption on the same model)?
An earlier report of GoAway-less closes
(idle case, here)
was answered at the time with “timeout and GOAWAY notification work correctly”. Our
measurements show a clean before/after break on Aug 3→4 plus a progressive decay since,
so this looks like a fresh, evolving server-side regression rather than a client issue.
Full sanitized JSONL logs of every nightly run since Aug 1 are available on request.