Pages site serves five dead dataset links until a publish tag picks up #53/#54

[mmcky]

Found during the independent validation tracked in QuantEcon/workspace-lectures#36, which checked this site because it was never re-fetched after #53/#54 merged.

What readers see right now

The live Pages site is stale pre-repoint HTML (last Pages build 2026-08-05T03:07Z, gh-pages e9156b95). Its french_rev.html still links assignat.xlsx, dette.xlsx and fig_3.xlsx via QuantEcon/lecture-python-intro/blob/main/lectures/datasets/, and its inflation_history.html still links chapter_3.xlsx (twice) and longprices.xls via the raw form of the same path. All five URLs return 404 today — those files were deleted from lecture-python-intro on Aug 6–7 (QuantEcon/lecture-python-intro#825 and QuantEcon/lecture-python-intro#827).

Main is already fixed

#53 and #54 repointed both lectures to data-lectures, and all five replacement targets serve real bytes today (assignat 209,555 B, dette 632,030 B, fig_3 9,466 B, chapter_3 73,281 B, longprices 388,608 B). The breakage lives only in the published HTML.

Why it has not cleared

publish.yml triggers on publish* tags only, and the last publish run was 2026-02-10 — merges do not republish this site. Pushing a publish* tag is the whole repair.

Why no automation caught it

The weekly linkcheck runs lychee over the gh-pages HTML, and these URLs sit in verbatim/code-cell content that lychee skips — so dead data links in published pages are invisible to it. Worth remembering when this canary is used to argue a publish path is healthy.

[mmcky]

Repaired. Tag publish-2026aug12 (source 8b4a9cf) pushed 2026-08-12; the "Publish to GitHub Pages" run completed success and the site is rebuilt from main.

The five dead links are gone, but not in the way this issue anticipated — worth recording, because the same reasoning applies to any future canary publish.

The pages no longer exist. _toc.yml was trimmed by #49 to five lectures and _config.yml:21 sets only_build_toc_files: true, so french_rev and inflation_history are not built at all; deploy-pages replaces the whole artifact rather than merging into it. Measured after the deploy:

Page	Before	After
french_rev.html	200, 3 dead dataset links	404
inflation_history.html	200, 2 dead dataset links	404
heavy_tails.html	200, 4 stale high_dim_data reads	404
inequality.html	200, 1 stale read	404
mle.html	200, 1 stale read — and that one was 404ing at the data URL	404
index.html, intro.html, short_path.html	200	200

So verify this by 404, not by content. The surviving pages are the trimmed toc, which is the intended state.

One thing this publish also fixed that was not in the issue. mle.html was not merely stale — it was serving a genuinely broken read: media.githubusercontent.com/media/QuantEcon/high_dim_data/**update_scf_noweights**/SCF_plus/SCF_plus_mini_no_weights.csv, HTTP 404. That URL pins a branch, and update_scf_noweights was deleted on 2026-07-15, twelve seconds after high_dim_data#6 merged. Archiving high_dim_data preserved main — every other stale read on this site still resolved 200 — but archiving cannot bring back a deleted branch. It is a clean demonstration of why the rule is "archive, never delete, and do not delete branches after archiving": the repo being archived is not what protects a reader; the ref surviving is.

And the reason nothing caught it. The weekly linkcheck runs lychee over the gh-pages HTML, and these URLs sit in verbatim/code-cell content that lychee skips. That is the part of this issue worth keeping after it closes — when this canary is used to argue a publish path is healthy, remember that dead data links in published pages are invisible to its own link checker.

Closing: the site is rebuilt, no page serves a dead dataset link, and main has been correct since #53/#54.