この変更で扱ったのは、実際の運用で起きやすい保守上の問題です。同じ購読対象が元の feed、ミラーエンドポイント、拡張アダプターのどれから入ってきても、キャッシュと配信層では同じソースとして扱う必要があります。リクエスト URL をそのまま識別子にすると、表示名変更、ミラー切り替え、設定更新によって重複配信や更新漏れが起きやすくなります。
プロジェクト概要
リポジトリ: RhoninSeiei/astrbot_plugin_rss_forwarder。
このプラグインでは、「何を購読しているか」と「どこから取得するか」を分けています。安定したソースキーをキャッシュ、重複排除、スケジューリングに使い、取得入口は RSS、Atom、ミラーエンドポイント、拡張アダプターから選べるようにします。表示名、取得先、配信先はそれぞれ独立して変更できます。
フローメモ
設定層はソースキー、表示ラベル、アダプター種別、配信先ルールを保持します。アダプターは外部コンテンツをタイトル、リンク、時刻、概要を持つ正規化 item へ変換します。その後のパイプラインがソースキー、item ID、正規リンク、発行時刻を組み合わせ、配信が必要かを判断します。
この分割により、購読設定の変更を扱いやすくなります。表示名の変更で重複排除キャッシュは無効になりません。ミラーエンドポイントを変更しても既存 item は新規扱いになりません。配信レンダラーも、item が RSS、Atom、その他の任意アダプターのどれから来たかを知る必要がありません。
実装メモ
明確にしておきたい境界は、「コンテンツがどう入るか」と「コンテンツをどう送るか」の分離です。ソースアダプターは小さな item モデルを返すところで役割を終え、要約、まとめ配信、翻訳、プレーンテキストへのフォールバックはスケジューラーと配信層が判断します。
テストでは、識別子の変化を重点的に扱う価値があります。パネル設定の編集、ソース一覧の更新、スケジューラー再起動、キャッシュ記録の再利用は、成功した取得処理だけを確認するよりも、重複配信や更新漏れを見つけやすいケースです。