This change addressed a practical maintenance issue: the same subscription may enter the system through an original feed, a mirror endpoint, or an extension adapter, but the cache and delivery layers should still treat it as the same source. If the request URL becomes the identity, renaming a source, switching mirrors, or refreshing settings can create duplicate delivery or missed updates.
Project Overview
Repository: RhoninSeiei/astrbot_plugin_rss_forwarder.
The plugin separates “what is being followed” from “where it is fetched.” A stable source key drives caching, deduplication, and scheduling, while the fetch entrypoint can come from RSS, Atom, a mirror endpoint, or an extension adapter. Display names, fetch endpoints, and delivery targets can then change independently.
Flow Notes
Configuration keeps the source key, display label, adapter type, and target rules. The adapter only converts outside content into normalized items with titles, links, timestamps, and summaries. The later pipeline combines source keys, item identifiers, canonical links, and publish times to decide whether delivery is needed.
That split makes subscription edits easier to reason about. Renaming a display label does not invalidate the deduplication cache. Changing a mirror endpoint does not make old items look new. Delivery rendering does not need to know whether an item came from RSS, Atom, or another optional adapter.
Implementation Lessons
The clearer boundary is between “how content enters the system” and “how content is sent out.” A source adapter returns a compact item model and stops there. The scheduler and delivery layer then decide whether to summarize, batch, translate, or fall back to plain text.
Tests are most valuable around identity changes: editing panel settings, refreshing source lists, restarting the scheduler, and replaying cache records. Those cases catch duplicate delivery and missing updates more reliably than only checking successful fetches.