article filters in view menu are not working #66

New issue

Open

opened 2026-07-28 10:09:00 -07:00 by serrebi · 1 comment

serrebi commented

2026-07-28 10:09:00 -07:00

Owner

Press ctrl+2 in the "all articles" list
mark an article as read
refresh feeds, or reload the list, and the "read" article is still showing, even though the "unread" filter is checked

1. Press ctrl+2 in the "all articles" list 2. mark an article as read 3. refresh feeds, or reload the list, and the "read" article is still showing, even though the "unread" filter is checked

serrebi commented

2026-07-28 10:29:48 -07:00

Author

Owner

Fixed and released in v1.124.4. Thanks for the clear repro — that was exactly the bug.

What was wrong: the read filter is applied by the server when a page is fetched (the view id carries an unread:/read: prefix). Once an article was already in the loaded list, nothing ever re-checked it:

The refresh top-up only merged new entries in — it never removed rows that had stopped matching, and it bailed out early when nothing new arrived (your exact case).
A refresh that changed nothing else skipped the list reload entirely, so F5 had no visible effect.
Re-selecting a view rendered the cached list verbatim, and each view keeps its own copy of an article, so one marked read in "All Articles" still looked unread in a cached category or feed view.

What changed: the read filter is now also applied at display time, alongside the existing media filter, keyed on the view id the list was fetched with. Rows are only re-evaluated when the list is (re)built — never on the mark-read path itself — so an article you just read stays put under your focus while you are still on it, and is gone on the next refresh, reload, or view switch. Marking read/unread also syncs onto that article's copies in other cached views, and a list that empties out now rebuilds fully so "No articles found." is announced instead of silence.

Covered by a new regression test file (tests/test_article_read_filter_staleness.py): the merge path with no new entries, an empty top-up page, Read Only mode, and the unfiltered view (which must keep showing everything).

The Windows installer for v1.124.4 is up; the macOS/Linux artifact build was dispatched.

Fixed and released in **v1.124.4**. Thanks for the clear repro — that was exactly the bug. **What was wrong:** the read filter is applied by the server when a page is fetched (the view id carries an `unread:`/`read:` prefix). Once an article was already in the loaded list, nothing ever re-checked it: - The refresh top-up only *merged new entries in* — it never removed rows that had stopped matching, and it bailed out early when nothing new arrived (your exact case). - A refresh that changed nothing else skipped the list reload entirely, so F5 had no visible effect. - Re-selecting a view rendered the cached list verbatim, and each view keeps its own copy of an article, so one marked read in "All Articles" still looked unread in a cached category or feed view. **What changed:** the read filter is now also applied at display time, alongside the existing media filter, keyed on the view id the list was fetched with. Rows are only re-evaluated when the list is (re)built — never on the mark-read path itself — so an article you just read stays put under your focus while you are still on it, and is gone on the next refresh, reload, or view switch. Marking read/unread also syncs onto that article's copies in other cached views, and a list that empties out now rebuilds fully so "No articles found." is announced instead of silence. Covered by a new regression test file (`tests/test_article_read_filter_staleness.py`): the merge path with no new entries, an empty top-up page, Read Only mode, and the unfiltered view (which must keep showing everything). The Windows installer for v1.124.4 is up; the macOS/Linux artifact build was dispatched.