Finding
FeedSchedulerService::refresh_feed, which dispatches to refresh_podcast_feed and refresh_news_feed, is not called in any test. service/tests.rs covers only subscribe_*, unsubscribe, mark_consumed, and the internal insert_new_*_episodes/articles helpers. The full poll path — conditional-GET fetch, parse, insert-new-items, update_subscription/update_feed, apply_retention, and event emission — is never exercised end-to-end.
Evidence
crates/komide/src/service/mod.rs:207
pub async fn refresh_feed(&self, feed_id: FeedId) -> Result<FeedRefreshResult, KomideError> {
grep -rn refresh_feed crates/komide/src/service/tests.rs returns no matches.
Why this matters
The conditional-GET caching logic (ETag / Last-Modified store then reuse), the update_subscription call that stamps last_checked_at, and retention application after insert are all correctness-critical and entirely untested. A regression in any of them — failing to update last_checked_at, applying retention before inserting new articles, or discarding new items on a spurious 304 — would silently corrupt feed state. On a counter-surveillance device, stale or dropped feed state degrades the freshness guarantees the user relies on without any visible error.
Desired correction
Add an integration test using an in-process mock HTTP server that serves a known RSS fixture, calls refresh_feed, and asserts: new items land in the DB, last_checked_at is updated, a FeedRefreshed event is emitted, and a second call answered with a 304 returns new_items = 0. Done when: refresh_feed is exercised for both podcast and news feed types in the test suite.
Finding
FeedSchedulerService::refresh_feed, which dispatches torefresh_podcast_feedandrefresh_news_feed, is not called in any test.service/tests.rscovers onlysubscribe_*,unsubscribe,mark_consumed, and the internalinsert_new_*_episodes/articleshelpers. The full poll path — conditional-GET fetch, parse, insert-new-items,update_subscription/update_feed,apply_retention, and event emission — is never exercised end-to-end.Evidence
crates/komide/src/service/mod.rs:207grep -rn refresh_feed crates/komide/src/service/tests.rsreturns no matches.Why this matters
The conditional-GET caching logic (ETag / Last-Modified store then reuse), the
update_subscriptioncall that stampslast_checked_at, and retention application after insert are all correctness-critical and entirely untested. A regression in any of them — failing to updatelast_checked_at, applying retention before inserting new articles, or discarding new items on a spurious 304 — would silently corrupt feed state. On a counter-surveillance device, stale or dropped feed state degrades the freshness guarantees the user relies on without any visible error.Desired correction
Add an integration test using an in-process mock HTTP server that serves a known RSS fixture, calls
refresh_feed, and asserts: new items land in the DB,last_checked_atis updated, aFeedRefreshedevent is emitted, and a second call answered with a 304 returnsnew_items = 0. Done when:refresh_feedis exercised for both podcast and news feed types in the test suite.