Repository navigation
polars: the FRED unemployment read times out on GitHub runners and fails edition builds #646
Description
polars.md reads US unemployment (UNRATE) live from fred.stlouisfed.org/graph/fredgraph.csv. The request intermittently times out, on GitHub-hosted runners and locally too, so a build that re-executes the lecture can fail. On 2026-10-12 it failed both French sync PRs (QuantEcon/lecture-python-programming.fr#95 and QuantEcon/lecture-python-programming.fr#96), neither of which touches polars.md.
Evidence. The execution report from run 38192437331 (polars.err.log) ends:
TimeoutError: object-store error: Generic HTTP error: Error performing HEAD https://fred.stlouisfed.org/graph/fredgraph.csv?…&id=UNRATE&…&vintage_date=2024-07-29&revision_date=2024-07-29… in 184.3s, after 5 retries … Connection timed out (os error 110)
FRED is unreliable from anywhere, not only from CI. Run locally the same afternoon, the French lecture executed cleanly. Minutes later, the identical cell in the English lecture hung on the same request until it hit a 600-second cell timeout. The code is fine; the request is what fails.
This series is exposed too. The English lecture has the same cell (polars.md, the exercise that builds fred_url). Its builds pass today only because the execution cache holds the lecture's outputs; the next time polars.md changes, or the cache is rebuilt, it can fail the same way.
A possible fix. The URL pins vintage_date=2024-07-29 and coed=2024-06-01, so the series it returns never changes. It can become a snapshot in QuantEcon/data-lectures, read with pl.read_csv from there, as the datasets migration did for test_pwt.csv in the same lecture (#612). The editions then pick the change up through their usual sync. The wider question of retries and status checks on dataset reads is QuantEcon/data-lectures#156.
🤖 Generated with Claude Code
Activity
mmcky commentedon Oct 12, 2026
More evidence, 2026-10-12: from GitHub's runners the failure looks persistent, not intermittent.
polars.mdsince 2026-10-07 has failed on this request: Update need_for_speed.md lecture-python-programming.fr#94 (2026-10-07), 🌐 [translation-sync] [autodiff] Open with a sentence that suits both series lecture-python-programming.fr#95 and 🌐 [translation-sync] [pandas_panel] Describe the single .replace() call, not a loop lecture-python-programming.fr#96 (2026-10-12), and re-runs of all three later the same day. That is six of six, each ending in the same timed-outHEADrequest tofredgraph.csv.observation_date,UNRATE. So the series is easy to snapshot exactly as the lecture reads it.Re-running a build does not clear it, so the snapshot route in the issue body is what will get edition builds green again. The vintage is pinned, so the file never needs refreshing.