[BUG]: Miniflux integration has sync issues

[arran4]

Brief description of the issue

There are synchronisation issues with the read / unread status with mini flux.

How to reproduce the bug?

1. Use it to navigate over unread items in and mark them as read
2. Wait for a sync to occur (in my case when focus is lost it seems)
3. Notice that after the sync things you marked as read become unread.

simplescreenrecorder-2022-11-10_21.48.48.mp4

Best job I could at capturing it

What was the expected result?

I expected read articles maintain status regardless of sync progress

What actually happened?

After sync with miniflux they unsynced.

Debug log

I will get back to you on this

Operating system and version

• OS:

% cat /etc/os-release 
PRETTY_NAME="Ubuntu 22.10"
NAME="Ubuntu"
VERSION_ID="22.10"
VERSION="22.10 (Kinetic Kudu)"
VERSION_CODENAME=kinetic
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=kinetic
LOGO=ubuntu-logo

• RSS Guard version:
  

[arran4]

time="    59.108" type="debug" -> feed-downloader: Downloading new messages for feed ID 'feed/26' URL: 'https://github.com/arran4' title: 'Private Feed for arran4' in thread: '0x7f20fe7fc6c0'.
time="    59.108" type="debug" -> database: SQLite connection 'feed_upd' is already active.
time="    59.108" type="debug" -> database: SQLite database connection 'feed_upd' to file '/home/arran/.config/RSS Guard 4/database/database.db' seems to be established.
time="    59.108" type="debug" -> feed-downloader: Downloaded 3 messages for feed ID 'feed/26' URL: 'https://github.com/arran4' title: 'Private Feed for arran4' in thread: '0x7f20fe7fc6c0'. Operation took 74 microseconds.
time="    59.108" type="debug" -> core: Filter accepts row 'arran4 (Gmail)' and filter result is: 'true'.
time="    59.108" type="debug" -> core: Filter accepts row 'arran4 (Gmail)' and filter result is: 'true'.
time="    59.108" type="debug" -> feed-downloader: Saving messages of feed ID 'feed/26' URL: 'https://github.com/arran4' title: 'Private Feed for arran4' in thread: '0x7f20fe7fc6c0'.
time="    59.108" type="debug" -> core: Updating messages in DB. Main thread: 'false'.
time="    59.108" type="debug" -> database: SQLite connection 'feed_upd' is already active.
time="    59.108" type="debug" -> database: SQLite database connection 'feed_upd' to file '/home/arran/.config/RSS Guard 4/database/database.db' seems to be established.
time="    59.109" type="debug" -> database: Checking if message with service-specific custom ID 'tag:google.com,2005:reader/item/000000000000790d' is present in DB.
time="    59.109" type="debug" -> feed-model: There is request to reload feed model, reloading the 1 items individually.
time="    59.109" type="debug" -> core: Filter accepts row 'Spam' and filter result is: 'true'.
time="    59.110" type="debug" -> core: Filter accepts row 'arran4 (Gmail)' and filter result is: 'true'.
time="    59.110" type="debug" -> core: Filter accepts row 'arran4 (Gmail)' and filter result is: 'true'.
time="    59.110" type="debug" -> database: Message with custom ID 'tag:google.com,2005:reader/item/000000000000790d' is already present in DB and has DB ID '23924'.
time="    59.110" type="debug" -> database: Overwriting message with title 'rogafe forked rogafe/golang-ical from arran4/golang-ical' URL 'https://github.com/rogafe/golang-ical' in DB.
time="    59.110" type="debug" -> database: Checking if message with service-specific custom ID 'tag:google.com,2005:reader/item/00000000000078fd' is present in DB.
time="    59.111" type="debug" -> feed-model: There is request to reload feed model, reloading the 1 items individually.

This seems to be the point the read status is removed.

[martinrotter]

I will check.

[martinrotter]

I performed testing with latest stable miniflux version and was not able to reproduce your problem. When I mark some articles read or unread, then the state is automatically and correctly synced back to Miniflux server. I added some more debug logging into the code.

Perhaps post full log here, but your log also does not suggest any problems so it is rather hard for me to see and detect the issue.

[arran4]

I will do some more testing to see how easy it is to replicate on a blank slate. Perhaps it's due to the volume of data.

It shows up consistently but only for a few items each time. It might be more biased towards the articles I open in an external browser now that I think about it.

It /feels/ like the data is being toggled rather than marked as read / not as read TBH. I have had some issues where marking a feed as read, then doing a "fetch all" will invert the status of all items. So if that's the same issue I suspect that me opening in an external browser is causing a double toggle. See video:

simplescreenrecorder-2022-12-02_11.35.38.mp4

[arran4]

@martinrotter Seems I can't reopen this. I guess that's up to you. Do you need any more info from me? Given my suspicions extra debug logging won't help.

[martinrotter]

Thats weird, will try.

[mmatous]

Similar issues here with 4.5.0. Opened Rssguard after a long time. Post-sync, RG reported 6k+ unread articles while Miniflux has only about 2k.
Removed & added the Miniflux account again. Clean sync now reports ~80 less unread articles than server. It's not a time window issue in RG, I set more than a year of leeway.
Read 2 articles in RG but only the second one got marked correctly on the server.
Opened several articles multiple times next and those got marked correctly.
I didn't manage to get log of the first failure, apologies, but some sync issues are def. still present.

[mustaruhtinas]

Still happens with 4.5.3.
1.8k unread in Miniflux, over 7k in RSSGuard - using intelligent download. Otherwise won't sync anything (progress is shown, downloading common data and then individual feeds, however article count - both read and unread - is 0).

[martinrotter]

@mustaruhtinas @mmatous

Can anyone provide Miniflux instance with testing account for me to test this stuff?

[mustaruhtinas]

@martinrotter
I'll set a user up on my instance and I'll send you the details once done.

[martinrotter]

sure, you can pm me on discord or my e-mail is visible in rssguard about dialog

[mustaruhtinas]

@martinrotter e-mail sent

[martinrotter]

miniflux/v2#2171
miniflux/v2#2172

[martinrotter]

Tested, it all should now work much better.

[mustaruhtinas]

I am not certain whether this is miniflux (google reader api) related or rssguard related, but I now experience the following behaviour: initial sync is now fixed, will have the same number of articles in both web interface and rssguard, but reading an article using the web interface (i.e. on mobile, or browser) seems not to sync its state in rssguard, so that the number of unread entries keeps adding up.

Using latest version (4.5.3) on an up-to-date git version miniflux.

[martinrotter]

i see, will check on monday

[martinrotter]

@mustaruhtinas

Pleast, provide PRECISE STEP-BY-STEP scenario on how to reproduce the issue with clean miniflux profile (only one feed added) and clean RSS Guard profile. I am not able to reproduce.

Synchronization is two-way and (depending on your configuration of miniflux in RSS Guard - see picture) you should always see same state in RSS Guard and other devices. Marking article read/unread on other devices should be visible in RSS Guard after you fetch the feed again too.

[mustaruhtinas]

Still happens here.
As per instructions, I created another miniflux user and a new rssguard profile.
Account options:

Added one feed, initial sync 30 unread items, in both web interface and rssguard.

Read one entry in web interface (29/30 unread items on server).

Fetched in rssguard, still 30 unread items.

[martinrotter]

You have "download unread articles only" option checked. If that option is checked, then only articles which are unread on the server are downloaded. You rarely ever want that option checked.

[mustaruhtinas]

Yes, that was the issue. In retrospect, seems obvious.
Working fine now, thanks.