Retry Grain API rate limits with exponential backoff

[dplakon]

Problem

Today's daily run of scripts/fetch_daily_meetings.py failed twice with:

RuntimeError: Grain API 429 on GET /recordings?includeParticipants=true&cursor=...: Too Many Requests

Two issues combined to make this fatal:

• list_all_recordings walks up to 100 pages back-to-back with no delay, so a busy account reliably trips Grain's rate limit.
• _get raised on the first non-2xx response, so one rate-limited page aborted the entire run — even though the earlier pages had succeeded.

hydrate_with_participants has the same problem: it makes one request per recording of the target day with no pacing.

Changes

• Added _request, a shared GET helper that retries 429 and transient 500/502/503/504/network errors with exponential backoff (6 attempts, starting at 2s), honoring the Retry-After header when Grain provides one.
• _get and get_transcript_text both route through the new helper, so transcript fetches in the per-meeting processor get the same protection.
• Added a small pause between paginated list requests and between per-recording hydration requests, tunable via the GRAINIAC_PAGE_DELAY env var (default 1.0 seconds).
• Retries log to stderr so a slow run is distinguishable from a hung one.

Verification

Before this change the fetch failed on the second page of pagination on two consecutive attempts, ~45s apart. After the change, the same command completed end to end:

$ python scripts/fetch_daily_meetings.py today
Resolved 'today' to 2026-08-19 (timezone: America/Los_Angeles)
Fetching recordings for 2026-08-19...
Fetched 2000 total recordings
Found 10 recordings on 2026-08-19
Hydrating 10 recordings with participant data...
Found 10 external customer meetings

The 10 meetings were then handed off to per-meeting child agents as usual.

[dplakon]

This PR was generated with Warp.

Comment @warp-agent on this PR to send it follow-up work.

 

[warp-factories]

Your Warp account is not a member of any team with access to this repository.