summaryrefslogtreecommitdiff
path: root/server/cmd
diff options
context:
space:
mode:
authorPeter Stone <thepeterstone@gmail.com>2026-11-06 09:08:14 +0000
committerPeter Stone <thepeterstone@gmail.com>2026-11-06 09:08:14 +0000
commit816118d8860093f3c9726b45c41c34c4a2751a2a (patch)
tree7daa61fad974695cd2bc727892601a14514cd032 /server/cmd
parentba3ca37897c12d2d285f48e8a429d47b40773df5 (diff)
A feed's failure is only worth saying once it has lasted a day
Peter opened the app to six shows in red, every one of them "Could not reach that feed". All six answered 200 when checked from the server a minute later. His guess was an auto-refresh on focus. There isn't one -- the only triggers are the button and a six-hourly worker -- and that makes it worse rather than better: what he was reading was a stale report of a connection that dropped during a background refresh hours earlier. The line survives until that feed next succeeds, and the worker is constrained to unmetered networks, so on mobile data "next" can be a long time. The error is still worth storing. A feed that has quietly stopped working is indistinguishable from one with nothing new, which is the whole reason it is kept rather than logged. But one miss is noise and a pattern is information, and the difference was already recorded: lastFetchedAtMs is the last time the feed actually worked. So a failure appears once a feed has gone a day without succeeding -- about four missed attempts at the current cadence. A dropped connection clears itself and is never seen; something genuinely broken still goes red, the same day. No schema change; the timestamp was already there. Two cases stay loud on purpose. A feed that has *never* succeeded reports immediately, because a subscription that failed the moment it was added is not a blip and somebody is waiting on it. And a success timestamp in the future is treated as no success, so a clock that has moved cannot hide a real failure indefinitely. Not changed, and worth deciding separately: the periodic refresh is unmetered-only, so on mobile data the library goes stale with nothing saying so. Adding a refresh on launch is now safe in a way it was not before -- the transient failures it would produce are exactly what this hides -- but it is a behaviour change nobody asked for. 1052 tests, detekt 0, lint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
Diffstat (limited to 'server/cmd')
0 files changed, 0 insertions, 0 deletions