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.
mmcky commentedon Oct 13, 2026
Fixed by #647. The cause turned out to be polars, not FRED's reliability.
Cause. polars 2.0.0 was released on 2026-10-06, and the lecture's
!pip install --upgrade polars yfinancepicks it up. polars 1.x fetched a URL with one plainGET. 2.0 goes through its object store instead: aHEADrequest for the file size first, then rangedGETs.FRED handles that
HEADbadly:HEADrequest times out. That is theError performing HEAD … after 5 retriesin the French logs above.content-length: 0, although the body is 13,809 bytes. polars 2.0 then stalls anyway.Ordinary
GETs work. That fits the evidence above:HEAD.GETand kept passing.Against the real URL,
pl.read_csv(fred_url, try_parse_dates=True)took 0.23 s under polars 1.44.2. Under 2.0.0 it was still running when I killed it after 90 s.Fix. #647 downloads the CSV with
requestsand passes the bytes topl.read_csv. That avoids theHEADentirely and gives the same 918 rows. It is confirmed on GitHub's runners under polars 2.0.0:polars.mdin 21.85 s.The French sync for #647 has run, so the French edition gets the same fix.
The snapshot in
data-lecturesis no longer needed to get builds green. It is still an option if you want the lecture to stop depending on FRED being up; QuantEcon/data-lectures#156 covers that wider question.Generated by Claude Code