Debug stale Economist RSS headlines (Go CLI)
Session from economist-tui-sessions on Hugging Face by thomasmustier · MIT · condensed by Coders Talk
3msession
0interventions
GOAL
Figure out why the economist-tui CLI keeps showing April 1st articles a day later, and whether updates are broken.
- +0Prompt · +0I'm only seeing articles from April 1st today (April 2nd). Do we know why? Are we not updating?
- +0mAgent did · +0mSearched the codebase and read through RSS fetching, caching, headlines, and browse command code to understand how sections and dates are handled.
- +0mAgent did · +0mTraced through browse.go, prefetch.go, source.go, read.go and browse.go command to see how the CLI picks sections and runs the fetch pipeline.
- +0mAgent did · +0mRan the CLI's headlines command directly and checked JSON output for leaders and finance sections; confirmed the top article dates were indeed stuck at April 1st.
- +1mFail · +1mFirst direct Python RSS fetch attempt failed with a urllib error.
- +1mAgent did · +1mAdded a user-agent header and queried the live Economist RSS feeds directly (leaders, briefing, finance, latest) across sections, comparing pubDate timestamps to the CLI's cached output.
- +1mFail · +1mGuessed at rss.xml URL and got a 404, then found the correct 'latest' feed URL returns fresh April 2nd content.
- +2mAgent did · +2mRead sections.go and cmd/sections.go, then ran the CLI's sections command to see the full list of available sections and confirm 'leaders' is the default versus a site-wide 'latest' feed.
- +3mOutcome · +3mDiagnosed root cause: the CLI defaults to the 'leaders' section (last updated Apr 1st) rather than a site-wide 'latest' feed (already showing Apr 2nd items); not a caching bug, no code fix applied yet.
VERDICT
Next time I'd ask directly to compare the 'leaders' feed against the site's 'latest' feed for freshness, since that's what actually mattered. The useful correction here was the agent's own move to hit the live RSS feeds directly with curl/python rather than trusting the app's cache, which is what revealed the real issue was a default-section choice, not a stale cache.