refresh-snapshots: a dynamic snapshot's builder is failing

[github-actions]

The weekly sources-alive canary failed. Nothing was written: every consumer keeps reading the last-good snapshot, so no lecture is affected — this is the alarm moving from the lecture repos' CI to here, doing its job.

us_business_cycle_monthly.csv — fetch failed (exit 1) — the upstream or the network, not the data. Re-run the workflow; if it fails again, the source has moved or gone.

Builder: builders/business_cycle_fred.py. Last lines of its log:

    version, status, reason = self._read_status()
                              ^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/http/client.py", line 304, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/socket.py", line 720, in readinto
    return self._sock.recv_into(b)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/ssl.py", line 1251, in recv_into
    return self.read(nbytes, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/ssl.py", line 1103, in read
    return self._sslobj.read(len, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: The read operation timed out

Run: https://github.com/QuantEcon/data-lectures/actions/runs/33476641282

Posted automatically. Later failures comment here rather than opening new issues, so close this once the canary is green.

[github-actions]

The weekly sources-alive canary failed. Nothing was written: every consumer keeps reading the last-good snapshot, so no lecture is affected — this is the alarm moving from the lecture repos' CI to here, doing its job.

us_business_cycle_monthly.csv — fetch failed (exit 1) — the upstream or the network, not the data. Re-run the workflow; if it fails again, the source has moved or gone.

Builder: builders/business_cycle_fred.py. Last lines of its log:

    version, status, reason = self._read_status()
                              ^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/http/client.py", line 304, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/socket.py", line 720, in readinto
    return self._sock.recv_into(b)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/ssl.py", line 1251, in recv_into
    return self.read(nbytes, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.12.14/x64/lib/python3.12/ssl.py", line 1103, in read
    return self._sslobj.read(len, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: The read operation timed out

Run: https://github.com/QuantEcon/data-lectures/actions/runs/33476834886

Posted automatically. Later failures comment here rather than opening new issues, so close this once the canary is green.

[mmcky]

Diagnosed — the classification above was right (a fetch failure, not the data), and the cause is now measured rather than guessed.

Two runs failed the same way: a 60-second read timeout on the first FRED request, while every World Bank leg passed. A throwaway probe on a GitHub-hosted runner (#116, closed) shows FRED's edge answering Python-urllib/3.12 and curl/8.5.0 in about 50 ms with the full 14,181-byte file, and stalling qeld-builder and even Mozilla/5.0 until the read times out. The same requests all succeed from a workstation — which is how the custom user agent survived local testing, and why the lecture repos' own builds (pandas, no custom agent) have always reached FRED from these runners.

Fix in #117: the Fred class sends no User-Agent by default, with the measurement recorded in its docstring; fred_data.py drops the same header. Also from these runs: the canary now runs one leg per builder instead of one per dataset (the World Bank builder was fetching three times), and the dataset dispatch input filters the canary as well as the refresh.

Worth keeping from this: the alarm fired on its first real outing, wrote nothing, and said which failure class it was — and the fix took a probe from the runner itself, because the failure does not reproduce anywhere else. This issue closes when a post-merge dispatch runs the FRED leg green.

[mmcky]

Verified green after the close: post-merge dispatch of refresh-snapshots after #117 (run 33478359372, 2026-09-01 06:37 UTC). The FRED leg fetched all six series with urllib's default agent and validated in about 25 seconds — overlap window 1919-01..2026-07, 0 cells revised — and the World Bank leg ran once rather than three times, one leg per builder. Nothing was due, so no refresh PR; notify skipped. Both sources are now under the weekly canary for real.

For the record, the alarm's first outing: it fired on a genuine fetch failure, wrote nothing, classified the failure correctly, and the fix needed a probe from a runner because the stall does not reproduce anywhere else (#116, closed).