Recovering from feed errors

[rEnr3n]

My situation is similar to #149 except I will likely be experiencing timeouts everyday depending on how heavy the internet is being used (Windows Update can be a huge sucker). Not to mention natural disasters can cut internet connection for days.

Is there a reason why feeds are not updated after 3 errors? Is it performance-wise? Shouldn't this be the responsibility of the user? I would prefer to not constantly check miniflux for network errors. I'm a forgetful person so this is a big issue for me. I believe the number indicator beside the Feeds menu is good enough to notify the user that something is wrong (maybe you can make it color red).

#288 will be a good complement for this. You can disable feeds that are invalid and retry the rest.

[somini]

Is there a reason why feeds are not updated after 3 errors?

I believe this is a reasonable thing to do, since it might indicate the feed is completely broken for some reason and it might need user intervention. There's no need to keep spamming the endpoint to get the same result all the time.

The number could be configured and some sort of exponential backoff implemented for the retry timings (not sure if this is done already).

[rEnr3n]

The number could be configured and some sort of exponential backoff implemented for the retry timings (not sure if this is done already).

I can't see that in the settings.

[somini]

I can't see that in the settings.

Yes, it's a feature request. :)

[dzaikos]

There's a reset-feed-errors command line option, which resets all the feed errors so Miniflux will try fetching again. You can use this in a cronjob (once a day/week/whatever) to force Miniflux to try again. I think this is a good compromise because (as mentioned) Miniflux isn't hitting the site with the failed feed regularly.

[somini]

# /etc/systemd/system/miniflux-reset.service
[Unit]
Description=Miniflux Feed Error Reset
Wants=miniflux.service

[Service]
Type=oneshot
EnvironmentFile=/etc/miniflux.conf
ExecStart=/etc/binaries/miniflux -debug -reset-feed-errors

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/miniflux-reset.timer
[Unit]
Description=Miniflux Feed Error Reset

[Timer]
RandomizedDelaySec=30m
OnCalendar=weekly

[Install]
WantedBy=multi-user.target

Works for me. Thanks @dzaikos

[schwantuschke]

There's a reset-feed-errors command line option, which resets all the feed errors so Miniflux will try fetching again. You can use this in a cronjob (once a day/week/whatever) to force Miniflux to try again. I think this is a good compromise because (as mentioned) Miniflux isn't hitting the site with the failed feed regularly.

I use miniflux-linux-amd64 -reset-feed-errors and get the message [INFO] The default value for DATABASE_URL is used but no errors are reset :(

[somini]

I use miniflux-linux-amd64 -reset-feed-errors and get the message [INFO] The default value for DATABASE_URL is used but no errors are reset :(

As the error says, you need to run it with the same environment as the server. Make sure to export DATABASE_URL="$SERVER_URL"

For that particular command, I think that's the only necessary argument.

[schwantuschke]

I use miniflux-linux-amd64 -reset-feed-errors and get the message [INFO] The default value for DATABASE_URL is used but no errors are reset :(

As the error says, you need to run it with the same environment as the server. Make sure to export DATABASE_URL="$SERVER_URL"

For that particular command, I think that's the only necessary argument.

Thank, that helps :)

[shizunge]

If we have a global option to update feed no matter what is the number of errors, (#956, #879)
Does it solve the problem?

[rEnr3n]

Yes.

[shizunge]

Hi All,
What do you think of the UI in #998.
I hide the option of All/Error feeds to keep the UI simple, avoid adding new elements.
Thanks,
Shizun

[codl]

I would much prefer if miniflux kept trying indefinitely with exponential backoff going up to like, a day or three. Adding a "fix everything" button to click on every time the network goes down feels like a kludge, and so does using -reset-feed-errors in a cron job.

[your-friend-alice]

looks like here's where the logic actually lives, if you wanted to remove it:

v2/storage/job.go

Line 25 in 264f4db

CASE WHEN $1 > 0 THEN parsing_error_count < $1 ELSE parsing_error_count >= 0 END

very limited workaround: looks like the number of retries is configurable: https://miniflux.app/docs/configuration.html#polling-parsing-error-limit. however, this could hammer your connection / a struggling server without also adding exponential backoff.

from my quick scan of the code, proper exponential backoff looks like this would require a model change to implement (add a field for next_retry_at) along with some more logic in the scheduler; not trivial but relatively small

[nickbp]

I'm running miniflux in a Kubernetes environment at home. In the cluster, the DNS service lives on one node, and if that node is down for too long then miniflux will silently stop refreshing all feeds.

I only notice this when I realize that none of my feeds have produced any results for several hours, and I need to manually go into the Miniflux UI to reenable the feed refreshes.