Feed edit option 'Mark updated articles as unread' conflicts with Filters

PLEASE READ THIS BEFORE POSTING: Read before posting / reporting bugs

Describe the problem you’re having:

‘Edit feed|Option tab’: ‘Mark updated articles as unread’ ticked/enabled conflicts with configured feed Filter ‘Match’ … ‘Mark as read’ action.

If possible include steps to reproduce the problem:

-Choose a feed with recurring article headlines.
-Configure filter regex expression(s) on selected feed to filter match ‘Title’ w/action ‘Mark as read’ for recurring articles.
-Wait.
-Once confirmed that filter(s) are working as expected…
-Go to ‘Preferences|Feeds’, select Feed, then in ‘Edit Feed’ popup window, Select ‘Options’ tab, tick/enable: ‘Mark updated articles as unread’. … Save.
-Wait.
-New articles matching filtered regex expressions for selected feed will now appear as unread instead of being moved to ‘Recently read’ .

For example: LWN.net

Filters working as expected / Key press: f D, and then force-rehash plus &xdebug=2

Debug output: LWN.net feed, w/filters - Pastebin.com

About a week or so later. Same Feed and Filters, now with Edit Feed | Option:‘Mark updated articles as unread’ ticked/enabled. Wait a week or so… Again, key press: f D, and then force-rehash plus &xdebug=2 … Filtering ‘seemingly’ not working.

Debug output: LWN.net feed, w/filters w/'Mark updated articles as unread' - Pastebin.com

tt-rss version (including git commit id):

v18.12 (dd9bad0)

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

ubuntu server 16.04.5, apache 2.4.x, php 7.0.x, postgres 9.5.x

Please provide any additional information below:

This problem occurs on multiple feeds. I believe this issue first appeared in the first couple of weeks of Dec 2018? idk? Just getting around to posting about it because … reasons. ;-(

.

if you want my opinion, this is one of those core options that should have never been added in the first place.

also i’m sorry but i’m not investigating this. my suggestion would be not using this option (same with on catchup show next feed), both of those are on the likely-to-be-axed list.

if someone else wants to investigate i’ll review the PR of course.

it’s possible but i don’t think december changes involved feed updates / filtering. it was mostly frontend stuff.

e: going by git log of classes/rssutils.php the only major change involved HOOK_FILTER_TRIGGERED

alright i’m looking at the code and it looks like mark_unread_on_update happens after filters so it overrides filter catchup action (and also force catchup which is used elsewhere), see https://git.tt-rss.org/fox/tt-rss/src/master/classes/rssutils.php#L1020

i don’t think that this option having the highest priority above filters and force catchup is warranted so i’ll change it to take those two into account which should likely fix this strange behavior

i still don’t like this option but it may yet escape the list of doom

e: also using force rehash and mark updates as unread is a ba-a-ad combination by design

e: https://git.tt-rss.org/fox/tt-rss/commit/13e7e775a383e2d6cf12ca1aa60099c0289560fb post here if i’ve broken everything with this change

30 minutes later:

Why the change of heart? Just curious.

i was bored

i. e. the usual cause