Gemini Live produces no output and the socket stalls immediately after interview starts

[davidtsai15]

Description

Jim never gives the opening greeting after the interview starts.

I first reproduced the issue using a older prebuilt macOS arm64 release (09d829e). In that build, the LiveKit room and Gemini session became ready, but the Gemini Live session immediately closed with WebSocket code 1011.

I then updated to the latest prebuilt macOS arm64 release (4874d8d). The user-visible symptom remained the same: Jim stayed silent and never delivered the opening response.

However, the newer build exposed a more detailed failure sequence. After the initial prompt, no Gemini output was received, later writes to the Gemini connection stalled, the socket stopped responding, and the subsequent resume attempt failed with an unexpected TLS EOF.

Environment

• OS: macOS 26.6.1
• Architecture: Apple Silicon / arm64
• Access method: http://127.0.0.1:3000/
• Gemini Live model: gemini-3.1-flash-live-preview

Older build

• Prebuilt macOS arm64 release binary
• Release commit: 09d829e

Latest build

• Prebuilt macOS arm64 release binary
• Release commit: 4874d8d

Steps to reproduce

1. Start CodeTrial with:

./codetrial web

2. Open http://127.0.0.1:3000/.
3. Start a coding interview.
4. Complete the media preflight.
5. Wait for the interviewer to join.
6. Observe that Jim never gives the opening greeting.
7. Check the CodeTrial terminal log.

Expected behavior

After the room and Gemini session become ready, Jim should give the opening greeting and continue the interview normally.

Actual behavior

Jim remains silent after the interview starts.

Older build behavior (09d829e)

provider pooling: 1 provider(s) over 1 project(s): primary=wss://codetrail-qh832isg.livekit.cloud
codetrial: open http://127.0.0.1:3000 in your browser
livekit quota: all 1 project(s) can take connections
codetrial dispatch room=interview-dq7uair1
joined room=interview-dq7uair1 identity=interviewer-interview-dq7uair1
starting interview: room=interview-dq7uair1 problem=contains-duplicate-ii duration=30min
timing: room and Gemini session ready 0.96s after the candidate joined

Immediately afterward, the Gemini Live session closes:

Gemini closed the session: code=1011 reason=Internal error encountered.
Gemini session restart degraded; resumption was unavailable and the interviewer is rebuilding from local transcript, editor and interview state

Jim never gives the opening greeting.

Latest build behavior (4874d8d)

After updating to the latest release, the room and Gemini session still become ready successfully:

codetrial dispatch room=interview-mmxq2fbd
joined room=interview-mmxq2fbd identity=interviewer-interview-mmxq2fbd
starting interview: room=interview-mmxq2fbd problem=search-insert-position duration=30min
timing: room and Gemini session ready 1.58s after the candidate joined

However, Gemini produces no output after the initial prompt:

timing: no output 20s after a prompt; returning the floor at=0:21.581 room=interview-mmxq2fbd

prompt: at=0:47.581 kind=nudge id=2 test_runs=0 evidenced= room=interview-mmxq2fbd

timing: no output 20s after a prompt; returning the floor at=1:07.582 room=interview-mmxq2fbd

The Gemini connection then becomes unresponsive:

Gemini write stalled for 5s, ending the session
Gemini audio write failed (Gemini write timed out); waiting for the close to be reported
Gemini audio write failed (Gemini socket stopped answering); waiting for the close to be reported

The attempt to resume the session also fails:

Gemini refused to resume (IO error: peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof); starting a fresh session instead

The visible result is still the same: Jim never speaks and the interview cannot proceed normally.

Additional investigation

I ran CodeTrial's built-in Gemini connectivity check using the same configuration:

./codetrial check-gemini --config config/codetrial.env.local

It succeeds:

provider pooling: 1 provider(s) over 1 project(s): primary=wss://codetrail-qh832isg.livekit.cloud
Gemini setupComplete: model=gemini-3.1-flash-live-preview voice=Puck problem=two-sum duration=45min
Not checked here: LiveKit credentials. This never calls LiveKit.

Therefore, the configured Gemini API key can establish a Gemini Live session and reach setupComplete.

I also created a new Google AI Studio project and generated a new Gemini API key. The connectivity check still succeeds, but actual interviews continue to exhibit the same user-visible failure.

I verified that the Gemini API quota for the project was still available and had not been exhausted when reproducing the issue. Therefore, the failure does not appear to be caused by an already-exhausted project quota.

I have not yet identified the exact condition that causes the Gemini Live connection to stop responding.

[quill0224]

I hit the same failure in the same window. Here is what I found: it has since recovered upstream.

• Git revision: 4874d8d (prebuilt macOS arm64 latest), the same symptom on an earlier prebuilt from 2026-09-25
• OS / browser: macOS 26.5 (Apple Silicon), Chrome
• Window: 2026-09-28, about 22:00 to at least 23:40 (UTC+8)

timing: room and Gemini session ready 0.53s after the candidate joined
Gemini closed the session: code=1011 reason=Internal error encountered.
replacement: at=0:11.314 resumed=true checkpoint_age=4s owed=true (candidate=true prompt=none tool=false) id=1 ...
prompt: at=0:11.319 kind=briefing id=2 ...
Gemini closed the session: code=1011 reason=Internal error encountered.

I reproduced this with a standalone WebSocket client using the live_setup fields, without CodeTrial or LiveKit, and with keys from two separate projects. During the window, any realtimeInput.text containing "candidate" got 1011 or no response. The same text with that one word swapped returned audio (3 runs each):

realtimeInput.text	Result
Say hello to the candidate.	3/3 1011
Say hello to the applicant.	3/3 OK
Name one candidate fruit for a smoothie.	3/3 fail
The user joined. Begin.	3/3 OK

The greeting() text alternated with Say hello in one sentence. failed 5/5 while the hello succeeded 5/5. Toggling the setup fields, and thinkingBudget: 0, made no difference. check-gemini stops at setupComplete without sending a turn, which is why it passed.

At 2026-09-29 11:06 (UTC+8), the same scripts succeeded on every input and Jim spoke again in CodeTrial, so this no longer reproduces on my side.

[jserv]

The 1011 resume loop is fixed by PR #213 (#198), which is in the latest release published today at cef474a2, and @quill0224 found the provider-side trigger cleared on 2026-09-29. Please retest on that release: if Jim greets you, this will be closed; if not, post the new terminal lines here.