NodeRSSBot Status

Supabase charge for Egress bandwith. Recently Demo comsure over 8G per month which exceeded their free plan. So I just increase the fetch gap for the demo. I may consider some alternatives for supbase when I have some free time from my job. The database is a PostgreSQL which a pg_cron extension to fixes some dead feed. It is around 50MB but read bandwidth is around 8G per month. Any suggestion?

Recoved after switching the pooling config to session mode in supabase dashboard.

The demo uses Supabase. Since Supabase has closed IPv4 connections, the demo has switched to an IPv6 network and testing shows that it can connect normally. However, recently there have been frequent errors of "relation 'xxx' not found," but restarting the bot restores to normal. The detailed reasons are still under investigation.

Service are being gradually restored

@noderss_bot will be down for maintenance now. Will recover soon

300 stars~

Demo is down for maintain.

A downtime occur from 2021-07-28T17:56 to 2021-07-28 18:16:08, everything should return to normal now.

All (1654) wechat-feeds subscribes are removed. https://github.com/hellodword/wechat-feeds/issues/3882
@noderss_bot itself is still working as usual.

Demo is back to normal now. A cron job is there to reduce the pressure of the server. Any subscribes to a feed which error count greater than 1350 (around 14 days because the fetch interval of the demo is 15min) will be deleted.

@noderss_bot is down for maintenance now. Some user may have see lots of "lookup timeout" message in recent days. It may be the issue of the infrastructure provider(the demo is running on Oracle Cloud) since I have not updated the running docker image for 4 weeks.

Thanks to docker buildx and GitHub action. Now pre-build docker image of multi architecture (linux/amd64,linux/arm64,linux/arm/v7,linux/arm/v6) is provided at fengkx/node_rssbot. You can now easily deploy NodeRSSBot on arm device like raspberry pi with docker.

The recent two releases both contains fetch-related improvements. In release v0.9.0 I have added handling of ttl values in RSS. We know that ttl values may not be understood in the same way, so there is a strict_ttl configuration for you to turn off this feature. If you turn it on, fetch_gap will be the fallback of ttl, and the fetch interval will be the ttl value. This may cause the delay in updates to be extended by up to one ttl. HTTP Caching support was added in release v0.10.0, a feature that honestly should have been implemented in the first place, but I never noticed it before. Every qualified RSS aggregators should implement this feature. This is a great help in reducing traffic to RSS feeds. This is especially true for Telegram RSSBot, which usually has a relatively short fetch interval. I hope that NodeRSSBot will be as eco-friendly as possible, rather than putting pressure on sites that still provide RSS feeds. This is why I recommend upgrading your own instance. Both of these releases include changes to the database table structure so their version numbers will look like this. But thanks to kenx migration such changes can usually be done automatically.

A downtime from 2021-03-02T01:54:49 (or earlier) to 2021-03-02T10:32:07 cause the @noderss_bot not sending any update. It is fixed in commit 70e5fab. It is cause by a feed which title contain html tag that telegram doesn't parse. Everything should return to normal now.

Recently, many of the new subscriptions in the demo came from a git repository called wechat-feeds that is mirrored at gitee. However this repository has been out of sync with the original GitHub repository for many days. All gitee subscriptions from this repository are purged to reduce the pressure on the demo. Due to the instability of WeChat RSS feeds, it is recommended that people who subscribe to this repository in large numbers use a self-built service. If the repository is no longer maintained, subscription links from its GitHub repository will also be cleared.