Repository navigation
Feed hosted on GitHub infra only persists 4 entries (document order); nginx feeds fine #5073
Description
Bug: Every feed hosted on GitHub infra only persists 4 entries; nginx-hosted feeds work fine
Platform: macOS Desktop (also reproduced on folo.is web, same account)
Describe the bug
For feeds hosted on GitHub infrastructure (GitHub Pages, raw.githubusercontent.com, gist.githubusercontent.com), a newly subscribed feed only ever shows exactly 4 entries — specifically the first 4 <item> elements in document order — regardless of feed content, size, item count, or XML structure. A control feed hosted on plain nginx (news.ycombinator.com/rss) shows all ~30 entries normally.
Repro feeds (all show 4 entries):
| URL | item count | notes |
|---|---|---|
| https://xlicz.github.io/podcast-rss/feed.xml | 176 | Chinese content, 1.9MB, content:encoded full text |
| https://xlicz.github.io/podcast-rss/feed-lite.xml | 176 | no content:encoded, 76KB, date-desc |
| https://xlicz.github.io/podcast-rss/feed-mini.xml | 50 | no content:encoded, 24KB |
| https://xlicz.github.io/podcast-rss/feed-t3-ascii.xml | 20 | 100% ASCII, standard channel, +0000 dates, 5.5KB |
| https://xlicz.github.io/podcast-rss/feed-t4-times.xml | 20 | ASCII, distinct per-item timestamps |
| https://xlicz.github.io/podcast-rss/feed-t7-three.xml | 3 | still shows 4 |
| https://gist.githubusercontent.com/xlicz/47d26652fdab176723ac95fbb5306987/raw/feed-t3-ascii.xml | 20 | same bytes as t3, gist origin |
| https://raw.githubusercontent.com/xlicz/podcast-rss/main/feed.xml | 176 | raw origin |
Eliminated hypotheses (each tested with a dedicated feed variant):
- feed size / partial transfer (24KB mini feed also shows 4; cold Pages fetch measured 1.1-1.4s total)
- robots.txt (deleted site robots.txt, still 4)
- content:encoded full-text HTML (stripped in lite/mini)
- single-line serialization (pretty-printed variants)
- guid isPermaLink="false" (removed in t2)
- non-ASCII titles/links (t3 is 100% ASCII)
- identical pubDates (t4 has distinct timestamps)
- channel meta order / language element / lastBuildDate (rebuilt channels)
- XML declaration style
Control that works: https://news.ycombinator.com/rss (nginx, ASCII, +0000) — shows all ~30 entries in the same account.
Key observation: the 4 displayed entries are always the first 4 in document order. A 3-item feed (t7) still displays 4. All failing feeds share: (a) GitHub CDN hosting, (b) same channel <link> value https://xlicz.github.io/podcast-rss.
Could this be related to GitHub-family URL detection (github.io / githubusercontent) in the server's fetch pipeline, or an entry-store preview limit where the async full-fetch job fails only for GitHub-hosted URLs?
Any server-side guidance (or a way to see why the async fetch fails) would be appreciated — the feeds themselves parse fine with ElementTree, feedparser, and r.jina.ai's reader.
Activity
xlicz commentedon Aug 14, 2026
Update with decisive evidence from the public API (GET https://api.folo.is/feeds?url=...&entriesLimit=N). Server-side ingestion truncates at document order, confirmed:
Hypothesis: initial import has a per-run time/processing budget and aborts silently mid-feed (varies with server load: 4, 7, 14, 16). Would appreciate confirmation of the intended backfill behavior - a feed with 186 items should not permanently show 4.
DIYgod commentedon Sep 27, 2026
Thanks for the detailed investigation. When a feed was first previewed, only its first few entries were parsed, but the ETag and Last-Modified of the response were saved with them. GitHub then answered the next refresh with 304 Not Modified, so the rest of the feed was never ingested until the document changed. Previews no longer save these validators, so the first refresh fetches the whole feed. Feeds that were already affected will catch up the next time their document changes. The fix will be included in the next release.