Read every recording-list page, and stop losing the GetTranscription race

[themightychris]

Problem

Two interception bugs make the CLI silently lossy.

1. Only the first page of the recording list is read. GetRecordingList is paginated at 10 items per page, and the web app issues one request per page. _intercept_grpc resolves on the first response, so only the newest page is ever seen. Recordings past page 1 can't be listed — and because transcript, download, and info all resolve audio_id through that same list, those recordings fail with Recording not found. Adding one new recording is enough to make a previously working recording unreachable. sync skips them and still reports success.

2. The GetTranscription settle window races the payload. The wait_for_largest branch resolves exactly 3s after listener registration, whether or not anything has arrived. When the page issues the call later than that (cold profile, slow network), the future is never resolved and the caller times out with The recording may not have a transcript yet — a cause it can't actually know. Roughly 40% of runs failed; retrying usually worked.

Fix

• _intercept_grpc_pages accumulates every GetRecordingList response and merges the item lists, deduped by id, returning the same [[items], token] shape the parsers already expect. Wired into all three call sites.
• The wait_for_largest settle window is measured from the last arrival rather than from registration, so it waits for the payload instead of racing it. It no longer gives up on its own — the caller's asyncio.wait_for supplies the deadline.
• List and transcript deadlines 30s → 60s to accommodate the settle window, and the transcript timeout message no longer asserts a cause it can't determine.

Verification

Real account, headless Chrome on Linux. sync over a library spanning two list pages:

	before	after
recordings listed	10 (page 1 only)	11 (all pages)
transcripts	5 of 8	8 of 8
audio	8 of 11	11 of 11
errors	3 timeouts	0

A recording that had been failing intermittently now succeeds 8/8 consecutive runs with a byte-identical 36,780-byte payload, including a 41-minute one. Existing 52 tests still pass.

Noted, not fixed

A recording whose list metadata reports has_transcript=true can still return an empty GetTranscription payload ([[[]]]). With the race fixed this no longer times out — instead the CLI writes a 0-byte file and prints Transcript saved. Whether to skip, warn, or error seemed like your call.

🤖 Generated with Claude Code