perf: bound RSS/Atom feeds to the most recent N posts (split from #154) #158

New issue

Closed

opened 2026-08-09 01:12:45 +00:00 by rosa · 1 comment

rosa commented

2026-08-09 01:12:45 +00:00

Owner

This was generated by AI during triage.

Split from #154. #154 tracks general pagination for the profile/tag/admin lists (a UX/design decision); this issue is the narrow, decision-free half: bound the RSS and Atom feeds to the most recent N posts.

Problem

The per-author feed queries select an author's public, live posts ORDER BY … DESC with no LIMIT. Every feed poll therefore serializes the author's entire public history into the response. Feed readers expect a bounded recent window, and payloads grow without bound as post count grows — the worst offender among the unbounded lists because feeds are polled continuously by external clients.

Scope

Cap the feed queries to the most recent N items only. No pagination, no UI, no cursor — feeds are a fixed recent window. See #154 for the profile/tag/admin listing work.

> *This was generated by AI during triage.* Split from #154. #154 tracks general pagination for the profile/tag/admin lists (a UX/design decision); this issue is the narrow, decision-free half: **bound the RSS and Atom feeds to the most recent N posts**. ## Problem The per-author feed queries select an author's public, live posts `ORDER BY … DESC` with no `LIMIT`. Every feed poll therefore serializes the author's entire public history into the response. Feed readers expect a bounded recent window, and payloads grow without bound as post count grows — the worst offender among the unbounded lists because feeds are polled continuously by external clients. ## Scope Cap the feed queries to the most recent N items only. No pagination, no UI, no cursor — feeds are a fixed recent window. See #154 for the profile/tag/admin listing work.

rosa added the

labels

2026-08-09 01:13:05 +00:00

rosa commented

2026-08-09 01:13:05 +00:00

Author

Owner

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Bound the RSS and Atom feeds to the most recent N posts instead of the author's entire public history.

Current behavior:
The feed handlers render a per-author RSS and Atom feed from the same underlying listing the Posts Service exposes for an author's public, live, public-visibility posts, ordered newest-first. That query has no limit, so a feed response contains every qualifying post the author has ever published and grows without bound.

Desired behavior:
Each feed contains only the most recent N qualifying posts (newest-first, same ordering and visibility rules as today). N is a fixed constant — pick a conventional feed window (20 is a reasonable default) and define it as a single named constant rather than a magic number. Posts beyond the window simply do not appear in the feed; there is no "next page" link (Atom pagination is explicitly out of scope). The limit is applied in the repository query, not by fetching everything and truncating in the handler or view-model.

Key interfaces:

The repository read that backs the feeds (the author's public/live/public-visibility posts, newest-first) should accept a bound and apply it in SQL. If that same read is shared by non-feed callers (e.g. the profile page) that must stay unbounded for now, add a bounded variant or an optional limit parameter rather than capping the shared query — the profile/tag/admin bounding is a separate concern tracked in #154.
The Posts Service method the feed handlers call should carry the limit through to the port; the web feed handlers themselves should not do the limiting.

Acceptance criteria:

An author's RSS feed contains at most N items.
An author's Atom feed contains at most N items.
The included items are the N most recent, with ordering and visibility unchanged from current behavior.
The limit is enforced in the repository query (verifiable: the SQL carries a LIMIT), not by post-fetch truncation.
N is a single named constant.
Non-feed listings (profile, tag, admin) are unchanged by this issue.

Out of scope:

Pagination or "next page" links in feeds (feeds are a fixed recent window).
Bounding or paginating the profile, tag, and admin lists (#154).
Making N configurable via env/config.

> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Bound the RSS and Atom feeds to the most recent N posts instead of the author's entire public history. **Current behavior:** The feed handlers render a per-author RSS and Atom feed from the same underlying listing the Posts Service exposes for an author's public, live, public-visibility posts, ordered newest-first. That query has no limit, so a feed response contains every qualifying post the author has ever published and grows without bound. **Desired behavior:** Each feed contains only the most recent N qualifying posts (newest-first, same ordering and visibility rules as today). N is a fixed constant — pick a conventional feed window (20 is a reasonable default) and define it as a single named constant rather than a magic number. Posts beyond the window simply do not appear in the feed; there is no "next page" link (Atom pagination is explicitly out of scope). The limit is applied in the repository query, not by fetching everything and truncating in the handler or view-model. **Key interfaces:** - The repository read that backs the feeds (the author's public/live/public-visibility posts, newest-first) should accept a bound and apply it in SQL. If that same read is shared by non-feed callers (e.g. the profile page) that must stay unbounded for now, add a bounded variant or an optional limit parameter rather than capping the shared query — the profile/tag/admin bounding is a separate concern tracked in #154. - The Posts Service method the feed handlers call should carry the limit through to the port; the web feed handlers themselves should not do the limiting. **Acceptance criteria:** - [ ] An author's RSS feed contains at most N items. - [ ] An author's Atom feed contains at most N items. - [ ] The included items are the N most recent, with ordering and visibility unchanged from current behavior. - [ ] The limit is enforced in the repository query (verifiable: the SQL carries a `LIMIT`), not by post-fetch truncation. - [ ] N is a single named constant. - [ ] Non-feed listings (profile, tag, admin) are unchanged by this issue. **Out of scope:** - Pagination or "next page" links in feeds (feeds are a fixed recent window). - Bounding or paginating the profile, tag, and admin lists (#154). - Making N configurable via env/config.

rosa referenced this issue

2026-08-09 04:25:52 +00:00

perf: post-listing queries are unbounded; paginate profile/feed/tag/admin lists #154

rosa referenced this issue from a commit

2026-08-09 18:03:46 +00:00

perf: bound RSS/Atom feeds to the most recent 20 posts

rosa closed this issue

2026-08-09 18:03:46 +00:00