-
Notifications
You must be signed in to change notification settings - Fork 35
feat: optionally prefer the feed's own title over readability's extracted title - #129
Conversation
...cted title readability's doc.title() is unreliable on some sites (e.g. it returns just the site name for every article on some blogs). The RSS feed's own <title> is usually accurate. Off by default to keep existing behavior unchanged; callers who hit this on a specific feed can opt in per source.
Smengerl
commented
Aug 9, 2026
Part of a merge-order check across all my open PRs (full breakdown on #124). This PR conflicts with #121 (both touch storyprovider/rss.py; #121 also separately conflicts with the config.py cluster — see #124). Suggested order: this PR first among the rss.py group → #134 → #135 → #128 → #127, with #121 merged last overall.
@j6k4m8
j6k4m8
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am somewhat ambivalent about these tests, they're meaningfully more sophisticated than the actual code they test and I worry they're not quite usefully testing the behavior we care about. I'm cool with leaving them in but I'm leaving this review note so that in the future if we encounter issues with them we can feel less bad about taking them back out :)
... constructor j6k4m8#129 added RSSFeedStoryProvider(prefer_feed_title=...) and described it as something callers could "opt in per source" - the same language used for every other per-source RSS option, all of which are set via the config file. But config.py's "rss" schema never listed prefer_feed_title as an optional field, and util.py's construct_story_providers_from_source_configs never passed it through even if it somehow got past validation. Concretely: {"type": "rss", ..., "prefer_feed_title": true} in a config file raises "Unknown field(s) in source #1: prefer_feed_title" - the option is unreachable from the CLI/config path j6k4m8#129's own description promised, only usable by constructing RSSFeedStoryProvider directly in Python. Wire it through the same way byline/body_source already are: add it to the "rss" schema's optional fields, validate it as a bool, and add it to util.py's allow-list.
Marks the PRs actually merged upstream since the table was last touched (j6k4m8#118-120, j6k4m8#122, j6k4m8#126, j6k4m8#129, j6k4m8#130, j6k4m8#134, j6k4m8#135, j6k4m8#137, j6k4m8#141), notes j6k4m8#123 as closed in favor of feature/puzzle-explanations, and adds the four rows that were missing entirely: j6k4m8#141 (fix/rss-absolute-url-wrapper-leak, merged), j6k4m8#142 (fix/rss-image-embedding, closed in favor of j6k4m8#145), j6k4m8#144 (fix/rss-prefer-feed-title-config-wiring, open), and j6k4m8#145 (feature/render-time-image-sizing, open).
Uh oh!
There was an error while loading. Please reload this page.
Summary
doc.title()is unreliable on some sites (e.g. it returns just the site name for every article on some blogs). The RSS feed's own<title>is usually accurate.prefer_feed_titleflag, off by default so existing behavior is unchanged; callers who hit this on a specific feed can opt in per source.Test plan
pytest goosepaper/storyprovider/test_rss.py- 11 passed (9 existing + 2 new: flag on -> feed title wins; flag off/default -> readability title unchanged)pytest) - 80 passedMerge overlap note
Verified by locally merging every pairwise combination of my currently open PRs against
master. This one produces a mechanical (non-semantic) merge conflict with #121 only - both add new parameters toRSSFeedStoryProvider.__init__at the same point. No overlap with any other currently open PR.