Closed Bug 1524241 Opened 6 years ago Closed 6 years ago

Thunderbird keeps automatically pausing updates for RSS feeds

Categories

(MailNews Core :: Feed Reader, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: post+mozilla, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

I have a couple of RSS feeds subscribed across several directories. Frequently, when I open the "Subscribe" menu to manage my RSS subscriptions, I find that quite a few of these feeds are greyed out and have their updates paused. I never manually paused updating a single feed, so I am not sure why Thunderbird keeps stopping to update these feeds -- but it is quite annoying, because it breaks the core functionality of the feed reader, which is to read the feeds.

Unfortunately, I found no way to reproduce this.

I first thought it might be related to RSS URLs having gone invalid, but that's not the case -- most of the ones that got disabled this time (8 feeds) work perfectly fine.

One of them is indeed broken for some reason, but even then just silently disabling the feed is a bad way to "tell" me about that problem.

Component: Untriaged → Feed Reader
Product: Thunderbird → MailNews Core

(In reply to Ralf Jung from comment #1)

I first thought it might be related to RSS URLs having gone invalid, but that's not the case -- most of the ones that got disabled this time (8 feeds) work perfectly fine.

No, that is definitely the case. At the moment of check, the file was unavailable. If you read the Learn More link, you will find out how to check the error console, where all these things are logged in detail.

One of them is indeed broken for some reason, but even then just silently disabling the feed is a bad way to "tell" me about that problem.

Disabling error state feeds is entirely by design. The folder containing a failed feed is shown with a red error triangle. All you have to do to reset this state is Get Messages on the folder, and if the feed has recovered, the pause state will revert to whatever setting it had before.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID

you will find out how to check the error console, where all these things are logged in detail.

The feeds are probably disabled for some time already so the logs are long gone from the console.

The folder containing a failed feed is shown with a red error triangle.

I have not seen a red error triangle for all but the one folder that contains the actually failing feed.

As far as I am concerned, I have set up by feeds, I got no indication of anything being wrong, and some weeks later I find out 7 of them have not been updated for an unknown amount of time even though they all work just fine right now.

All you have to do to reset this state is Get Messages on the folder, and if the feed has recovered, the pause state will revert to whatever setting it had before.

Ah, that's helpful! I thought I had to go to the settings.
Does the global "Get all Messages" also trigger this?

(In reply to Ralf Jung from comment #3)

you will find out how to check the error console, where all these things are logged in detail.

The feeds are probably disabled for some time already so the logs are long gone from the console.

The folder containing a failed feed is shown with a red error triangle.

I have not seen a red error triangle for all but the one folder that contains the actually failing feed.

You're correct, there are 2 problems so that some errors are incorrectly not indicated. To be fixed in a new bug.. Thanks.

As far as I am concerned, I have set up by feeds, I got no indication of anything being wrong, and some weeks later I find out 7 of them have not been updated for an unknown amount of time even though they all work just fine right now.

All you have to do to reset this state is Get Messages on the folder, and if the feed has recovered, the pause state will revert to whatever setting it had before.

Ah, that's helpful! I thought I had to go to the settings.
Does the global "Get all Messages" also trigger this?

Yes, that is a manual action and overrides both user pause and error pause, for all subfolders/feeds in the account root folder.

Error feedback for unknown domain error without a network error code and retry will be fixed in Bug 1524638.

I think this should be reopened. I just realized that half a dozen of my subscriptions were suspended for an unknown amount of time. I never noticed any notification for any of them being disabled. I have restarted Thunderbird countless times, and probably also clicked the global "Get Messages" on some occasion, but the subscriptions remained disabled and I didn't even realize.

Just because an RSS feed fails to fetch now, is not a good reason to disable it until some manual intervention without any kind of persistent notification. When a feed is dead, I'd like to remove it or update the URL; silently disabling it is probably the least useful reaction.

This is with Thunderbird 60. (Updating TB will be hard as not all of my extensions can be ported, from what it seems.)

I agree this needs to be reopened and addressed properly. The entire way this is handled represents bad design.

A cryptic (for the average user) error message buried in a seldom used window accessed from a seldom used submenu of a seldom used menu is not "notification" in any sense of the word. A notification isn't something one has to go looking for... it comes to you. There are no other indications of any kind that signal an actual problem... just the unexplained pausing of the feed which could have been done intentionally and thus makes for a terrible indicator for an error state. In fact, it could be said that Thunderbird actively masks the problem... as any user who makes active use of the ability to pause certain feeds is unlikely to notice when a feed has be automatically paused as a result of an error state.

And the fact that the feed is paused upon a single failure flies in the face of some of the most ubiquitous and fundamental network software design principles their are. Temporary network failures should be treated as an expected condition and software should be designed such that minimal interruption of service occurs. This principle dates all the way back to DARPAnet in the 1940s and is one the the most fundamental principles of computer networking. The current design of Thunderbird accomplishes the exact opposite... turning temporary failures into indefinite ones.

FWIW:

  1. I currently have 31 active feeds
  2. As of this instant 2 are Paused, which I did not set
  3. A more typical number of paused feeds is 8-10
  4. Multiply the number above that go Paused in a single day and this number can be as high as 30 over the period of a day.
  5. It is at least annoying to be forced to manually unPause these feeds multiple times in a single day.
  6. I agree that this is bad design and needs attention.

Same here..

3 Feeds, 1 fails every day and 1 most of the time.

This is really bad software design and should be fixed.
If an email server fails, TB manages to show a persistent notification iirc.

Never make temporarily errors to persistent ones.

Blocks: 1656651

I agree that there should at least be some way to disable this behavior. I have a somewhat spotty internet connection, and every time I have an outage I have to go in and restart half of my feeds. This didn't happen in Thunderbird a few years ago.

I also hope this will be fixed. It renders RSS not very usable in thunderbird ... most of the feeds do seem to fail periodically which means they stay auto-paused until you manually reset each category.

+1 for this one... this has been pestering for a long long time.

I believe this happens when the website is accelerated (cloudflare for instance) and site goes down temporarily (then cloudflare "gateway timeout" error page is displayed instead).

Please add an option not to pause RSS when the feed fails, it is very annoying to need to see it as paused and then noticing I missed several notifies. :(

You need to log in before you can comment on or make changes to this bug.