[BUG] Local changes to messages are sometimes not synced back to server and are forgotten

[pcause]

I had been using the 3.8.4 exclusively since yesterday for tt-rss. I don't enable auto update. I have a filter that marks all items in one category as read if they don't have a label. I sync and read things and repeat an hour or 2 later. I just did a sync and while the web interface shows:

tt-rss shows 570 items as unread and rssguard shows 70.

I am only sync'ing unread and the web view is also unread. Did another sync while writing this article and the difference is still there with a small delta (5) that are likely new articles.

Sorry don't have any debug. I deleted the database and am trying a fresh sync to see if things match. Will update after.

[pcause]

after deleted database and syncing in the tt-rss the numbers match.

[martinrotter]

I will check it out too.

[martinrotter]

@pcause Just thinking, could the difference between unread messages in RSS Guard and unread messages in TT-RSS server be caused by improper synchronization of unread->read message state change back to server from RSS Guard?

In this case, the FULL log from whole time you run RSS Guard would help.

[martinrotter]

My internal list of TODO:

• [x] Make sure that CacheForServiceRoot::saveCacheToFile is run automatically each time the cache is changed (something added or removed from cache)
• [x] Make sure that if client -> server message state change synchronization in ServiceRoot::saveAllCachedData fails, then those failed states are pushed back to cache, so that re-synchronization is attempted later again and states are not dropped without synchronization.
  • [x] TT-RSS,
  • [x] Inoreader,
  • [x] Nextcloud,
  • [x] Gmail
• [x] Regular message changes syncing is using async = true parameter. Remove the parameter and use feedDownloaderThread to the the job.
• [x] Inoreader somehow does not support (or is bugged) marking messages as UNREAD?
• [ ] Make sure that cache is pushed to server just before user edits account in RSS Guard and clear the cache subsequently, even if previous re-synchronization fails.

@pcause It might happen, in some cases, that if RSS Guard gets closed (for example by shutting down PC) that your cached message changes are forgotten and not pushed back to server, hence you see the message as marked as read in RSS Guard but the change never made it back to the server. Also if the pushing back fails (for example for network issues), then the change is simply thrown out and thus again, message change is not pushed back to server. I will address these issue and I think it should resolve your situation too.

[pcause]

definitely could and most likely is something with sync BUT I know that tt-rss has made a few changes and some caused duplicate items to appear. You might handle this differently in terms of the logic you use to detect a dup versus tt-rss. But I did examine and there are definitely new items in tt-rss that are unread, new not duplicated that aren't getting sycned.

BTW, thanks for the alternating backgrounds in the message list. makes scanning much easier.

[martinrotter]

@pcause Checkout dev. build for bf0c1439 when it gets compiled, it should be more reliable.

[martinrotter]

OK, now unsynchronized changes should not be forgotten for TT-RSS and should be re-synchronized again once per minute if previous attempt fails. Also, synchronizing mechanism is gracefully interupted if rssguard is about to quit.

[pcause]

if I start a sync will that forcce any changes that are stored locally and haven't been pushed to be pushed?

[martinrotter]

No, at this point, synchronization of message states happens:

• in 1 minute intervals automatically
• if you "update" (download messages) some feeds either manually or via auto-update policy

That said, I could certainly add "Synchronize message changes" button to account context menus. Create separate feature request for that. :)

[martinrotter]

This feature is not yet done, I must rewrite some code for other plugins as well and polish it all, but from practical POV it should basically work now much better for TT-RSS.

[martinrotter]

@pcause I implemented the button:

[martinrotter]

OK last not done point "Make sure that cache is pushed to server just before user edits account in RSS Guard and clear the cache subsequently, even if previous re-synchronization fails." will be implemented as part of #336.