Order the public article listing by publish date

[ssavutu]

Erik reported that a story published this morning never appeared on the home page. It was published, filed under News, and served fine at its own URL — it just was not in the listing anywhere a reader would look.

What was wrong

queryArticles ordered the public listing by id, so placement followed insert order rather than publish date.

The article held id 77. Everything else published that day held ids above 10082 — 77 is an id the CMS issued before an ETL reseed loaded the legacy archive above it. Ordering by id put a story published at 9am today at offset 10027 of 10050, between rows from 2011:

81  2011-04-08  students-plan-21st-century-drexel
80  2011-04-08  cab-announces-spring-jam-lineup
77  2026-08-07  data-centers-expanding-to-philly-area   <- here
66  2017-12-01  beyond-disrespect

The homepage news block reads 13 slots, so it never had a chance. I swept all 10,050 articles: this is currently the only 2026-dated row with an id below 9000, but any other draft created before the reseed will do the same thing the day it is published.

The fix

Public reads now sort by pub_date DESC, id DESC. One change covers the homepage, the section pages and /v1/articles, since all three go through queryArticles, and it matches what search and GetFeaturedArticle already did. id stays as the tiebreak — a whole issue publishes on one timestamp and needs a stable order within it.

Editors keep id DESC. Their listing carries drafts, whose pub_date is NULL and would sort to the very end, burying a new draft on the last page of a 10k-article list. That is the same reasoning articleOrderByClause already encodes for their explicit date sorts, and there is a test pinning it so the two branches do not later get collapsed into one.

Also adds idx_articles_pub_date (pub_date, id), wired in non-fatally alongside the other index builds — without it the new ordering filesorts the whole migrated corpus on every public request. Verified against MariaDB 11.8 that the ALTER is idempotent and the planner picks it up (range idx_articles_pub_date, no Using filesort).

Testing

New integration test seeds the exact live shape: a low-id row with today's pub_date among high-id archive rows. I checked it is not vacuous by reverting the fix and confirming it fails with the production symptom:

listing order = [todays-first-story todays-other-story last-issues-story an-archive-story drafted-before-the-reseed]
                  want drafted-before-the-reseed in position 3

go build, go vet and the full go test ./... pass on this branch's merge base, run against a MariaDB 11.8 container so the integration tests actually executed rather than skipping on an absent CMS_TEST_DSN.

Notes for review

• This fixes placement from the next deploy onward. It does not retroactively move Erik's article, though that article will land in its correct slot once this ships. Featuring it is still the zero-deploy workaround if the desk needs it up sooner.
• I never confirmed why row 77 got a low id — I could not reach the Delta host to check its creation_date. The drafted-before-the-reseed theory fits all the evidence but is unverified. Worth someone with DB access confirming, since it predicts more of these as old drafts get published.

🤖 Generated with Claude Code