feedback_feedreader_alarm_vs_explicit_refresh.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

---
name: feedback-feedreader-alarm-vs-explicit-refresh
description: "feedreader refresh model is alarm + fetch-on-launch + explicit button, not alarm-vs-explicit-only"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: d248310c-6c0c-43d3-8ae2-1e765347624b
  modified: 2026-08-22T22:42:36.554Z
---

When the user asked for "an explicit refresh button and only refresh on fresh open or explicit refresh," I removed the 5am morning alarm (MorningFetchReceiver) along with the hourly periodic WorkManager job. The user immediately corrected: they wanted the periodic job gone but the alarm kept — "I want the alarm... might want to know if there are new articles without screwing up the list ordering, but that's less important."

**Why:** the user's phrasing wasn't a literal spec ("only these two triggers") — it was really about killing the noisy/unpredictable hourly polling, not the specific once-a-day alarm they'd deliberately asked for earlier in the same session. Don't over-apply a stated constraint to every mechanism that superficially fits the same category ("background trigger") when only one instance of it was actually the complaint.

**How to apply:** feedreader's refresh model is now: fetch on cold launch, fetch via the explicit refresh button (Unread/Older top bar), and the 5am exact alarm — no periodic hourly job. If asked to touch refresh behavior again, keep the 5am alarm unless told otherwise.

Also flagged, lower priority, not yet implemented: a background/alarm fetch arriving while the Unread list is open can reorder visible rows (new articles insert by publishedAt DESC). The existing "N new articles" snackbar already surfaces the count; the ask is to also avoid the reorder/jump, but the user called this less important than getting the alarm back.