Skip to content

open_file 18s polling timeout causes false 'recording not found' on phone calls #356

@liususan091219

Description

@liususan091219

Bug

When open_file is called without a path (to open the latest recording), the old code polled up to 18 seconds waiting for the subtitled version:

for (let i = 0; i < 10; i++) {
  recPath = findRecording();
  if (recPath && recPath.includes('-subtitled')) break;
  if (recPath && i < 6) { await new Promise(r => setTimeout(r, 3000)); continue; }
  if (!recPath) { await new Promise(r => setTimeout(r, 2000)); }
  else break;
}

On phone calls, Gemini Live's tool-call timeout (~10-15s) would cancel the poll mid-retry. The model would then report "I couldn't find the recording" even though the narrated file was sitting on disk.

Root cause

The subtitle burn-in runs async after recording stops and takes ~30 seconds. The 18s polling loop was too short to catch it and too long for Gemini's tool timeout.

Fix

PR #353 removes the polling loop. open_file now:

  1. Calls findRecording() once — returns immediately with best-available version (subtitled > narrated > raw)
  2. Adds subtitled_pending flag and version field to the response
  3. Includes model instructions to tell the user subtitles are still generating and offer to retry

POC

bash scripts/poc-pr353-open-file.sh — 11/11 tests pass, including:

  • Phase 0: Reproduces the bug by running the exact old polling loop — confirms 7 iterations, 18000ms wait, never finds subtitled
  • Phase 1-3: Verifies the fix — new code returns in ~99μs with subtitled_pending=true

Linked PR

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions