# RSS Polling may take 20 minutes and more to process a feed

**URL:** https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322
**Category:** UX
**Tags:** rss-polling, fixed
**Created:** [13 september 2026 om 20:41 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322 "2026-09-13T20:41:42Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [13 september 2026 om 20:41 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/1 "2026-09-13T20:41:42Z")

</div>

Hi, first of all, thank you very much for the new RSS Polling admin interface. It makes such a difference!

We have a website with dozens of RSS feeds. I have noticed in Sidekiq that some jobs for some feeds may take twenty minutes and more. This easily clogs the queue.

There is a setting `RSS polling feed request timeout` but this is not the problem. The RSS feed is quickly available and it loads fast (at least when I try with my browser at the same time that Sidekiq is struggling with the same feed). The problem seems to be that some RSS feeds contain all the episodes of a podcast (as opposed to just the 10-15 most recent) AND that Discourse seems to process all those entries even if the episodes are already downloaded and without changes. Basically, Sidekiq can be easily struggling for half hour or more due to RSS feeds that bring no changes, no new episodes.

Ideally, Discourse would quickly see that there are no changes and move on.

Optionally, there could be a setting to limit the reading to the first NN entries of the feed.

Or at the very least, a time limit to end a polling if it isn’t resolved after NN minutes (5 minutes, or 10 at most)

I wonder what exactly happens when a feed takes more than 10 minutes to be processed and Sidekiq is 100% busy. What exactly can take that long and be so heavy to process.

Do you think this is something that could be improved in the current plugin?

---

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [14 september 2026 om 08:22 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/2 "2026-09-14T08:22:29Z")

</div>

i’d be happy to improve this, would you be able to share the url of your feed so that i can better test locally? (feel free to pm me if you want it kept private)

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [14 september 2026 om 09:18 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/4 "2026-09-14T09:18:16Z")

</div>

Thank you very much @zogstrip for your quick reply! The RSS feeds are public, and in fact recommended for whoever likes to listen independent podkasts and radio programs in Spanish. 😉

We keep the list of valid RSS feeds that we have temporarily disabled to give our server some breath here: [Limpieza de RSS feeds - nº 3 por icaria36 - Sobre Podkasts - Podkasts](https://red.podkasts.org/t/limpieza-de-rss-feeds/48863/3?u=icaria36)

Many of them use WordPress and we can ask them to edit the number of entries in their RSS. But many use iVoox, a popular platform at least in Spanish speaking countries. They ship all the episodes of a program in their RSS, they are a (relatively) big company, and it is difficult to even find a “Contact us” link that will lead to someone. So we are stuck there. For your test, I would start adding the iVoox feeds, and then go for more if you want more.

PS: you can start with one, unusually long: [\<![CDATA[Es lo que hay - Lliure directe]]\>](https://feeds.ivoox.com/feed_fg_f1649442_filtro_1.xml)

---

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [15 september 2026 om 08:27 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/5 "2026-09-15T08:27:09Z")

</div>

i have a couple prs in the work that should drastically improve the speed of polling/importing large feeds

> <https://github.com/discourse/discourse/pull/43643>
>
> Previously, \`TopicEmbed.topic\_embed\_by\_url\` matched \`embed\_url\` with a case-inse…nsitive regex, which can't use an index, so every lookup scanned the whole \`topic\_embeds\` table. RSS polling runs this lookup for every item of every feed on every poll, so re-polling an unchanged 1,600-item feed took ~230s on a site with 100k embeds.
> 
> This change matches \`lower(embed\_url)\` against the \`http\` and \`https\` variants of the normalized URL and adds an index on that expression, bringing the same re-poll down to ~5s. The oldest match is picked in Ruby instead of with \`ORDER BY id LIMIT 1\` because, until the new index has statistics, Postgres would walk the primary key rather than use it. Re-imports also compare \`user\_id\`s instead of loading the post's user for every item.
> 
> Reported at https://meta.discourse.org/t/412322

> <https://github.com/discourse/discourse/pull/43644>
>
> Previously, \`ImportedTopics\` matched every feed item URL in a single \`embed\_url …~\* ANY(ARRAY\[...\])\` query. Postgres only caches 32 compiled regexes, so with more patterns it recompiles them for every row it checks. With \`rss\_polling\_update\_tags\` disabled, a 1,600-item feed took ~25 minutes per poll on a site with 100k embeds.
> 
> This change looks topics up with \`TopicEmbed.with\_embed\_urls\`, which uses the \`lower(embed\_url)\` index (~0.1s for the same feed), only loads the columns it needs, and builds lookup keys with \`TopicEmbed.embed\_url\_key\` so they can't drift from the core query.
> 
> Reported at https://meta.discourse.org/t/412322
> 
> Stacked on https://github.com/discourse/discourse/pull/43643

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [15 september 2026 om 08:44 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/6 "2026-09-15T08:44:30Z")

</div>

**O M G !!!**

Thank you so much! That was quick and precise.

I’m very happy of our little contribution reporting this problem. Even if our case is quite a corner case (I guess?), the solution will contribute at a smaller degree to the performance of basically any Discourse instance using this plugin.

I see the patches are merged. Does this mean that we can get them by updating Discourse now?

---

<div class="post-metadata">

### Author: ![Moin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/moin/32/554653_2.png) [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [15 september 2026 om 09:00 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/7 "2026-09-15T09:00:06Z")

</div>

Merged means that the changes are in `main`. Usually, forums don’t track the main branch; instead, they track `latest`. This means that after merging, you still have to wait for the automatic tests to run and pass.

When you are looking at [Commits · discourse/discourse · GitHub](https://github.com/discourse/discourse/commits/main), you can see that this has just happened with zogstrip’s commits (there is a green check mark, while the commit above still has the brown dot).

 ![image](https://global.discourse-cdn.com/meta/original/4X/8/3/d/83d74f69e9f69b1aadeef036516198d50f620bb0.png)

And you can now also see the commits when looking at the `latest` branch: [Commits · discourse/discourse · GitHub](https://github.com/discourse/discourse/commits/latest)

So if you are tracking `latest`, which forums do by default, you can update now to pull those commits.

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [15 september 2026 om 11:55 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/8 "2026-09-15T11:55:20Z")

</div>

I have reenabled the RSS feeds and the first RSS round has mostly gone through. 86 new posts have appeared, many of them from days ago, which means that several feeds were not able to complete their processing before, and now they have. Very good!

Very long feeds still can keep a job busy for a long time, but I have only seen 3 going beyond 10 minutes. [This one](https://feeds.ivoox.com/feed_fg_f19404_filtro_1.xml) is still running after 1 hour… But it is really long, so maybe it is justified? Then again, a single feed taking one job for so long is kind of problematic in itself. Maybe it has to do with being the first full import in a while? I will check again in the next RSS round (we have it set to 180 minutes).

 ![image](https://global.discourse-cdn.com/meta/original/4X/7/c/4/7c4b61993054cff48a157408dc20ab7a76d2a2bb.png)

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [15 september 2026 om 12:02 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/9 "2026-09-15T12:02:33Z")

</div>

Maybe that job running during one hour is stuck on something beyond the import? I have just noticed that all the posts of that feed seem to have been imported, with images and everything. At least from the user point of view, the import seems to be done. Maybe it’s an outlier. I will report again after a couple more RSS rounds.

---

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [15 september 2026 om 13:20 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/10 "2026-09-15T13:20:15Z")

</div>

> [@icaria36](#):
>
> I have reenabled the RSS feeds and the first RSS round has mostly gone through. 86 new posts have appeared, many of them from days ago, which means that several feeds were not able to complete their processing before, and now they have. Very good!

nice 👍

> [@icaria36](#):
>
> Very long feeds still can keep a job busy for a long time, but I have only seen 3 going beyond 10 minutes. [This one](https://feeds.ivoox.com/feed_fg_f19404_filtro_1.xml) is still running after 1 hour… But it is really long, so maybe it is justified? Then again, a single feed taking one job for so long is kind of problematic in itself. Maybe it has to do with being the first full import in a while? I will check again in the next RSS round (we have it set to 180 minutes).

are those feeds “new” or have they all been already imported? i haven’t done much when it comes to improving how fast we do the initial import as this is largely limited by how “fast” we can create new topic.

---

<div class="post-metadata">

### Author: ![icaria36](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/icaria36/32/426431_2.png) [@icaria36](https://meta.discourse.org/u/icaria36)
#### Post date: [16 september 2026 om 11:22 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/11 "2026-09-16T11:22:20Z")

</div>

> [@zogstrip](#):
>
> are those feeds “new” or have they all been already imported?

They are all already imported.

Ok, we have changed the polling frequency to 10 minutes for the sake of testing (we will bring it back to 180 minutes, good enough for us). After zogstrip’s fix, most feeds are processed within a minute or less. There is only a couple of very long feeds that can get to 2 minutes and beyond, but never (that I have seen) beyond 5 minutes. [This RSS feed](https://feeds.ivoox.com/feed_fg_f19404_filtro_1.xml) is the only one that reliably gets to 4 minutes or more, but it is extremely long, so I’m not sure much can be done about this use case. Even the browser needs while to just render it. (And we might remove it for unrelated reasons.)

The fact that the entire polling process doesn’t take more than 5-6 minutes is astounding. A huge improvement. For me, this report can be resolved. Thank you very much again, @zogstrip.

---

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [16 september 2026 om 12:05 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/12 "2026-09-16T12:05:39Z")

</div>

![Keanu Reeves: My Pleasure](https://static.klipy.com/ii/d7aec6f6f171607374b2065c836f92f4/dc/0f/J81CSpis.webp)

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [18 september 2026 om 12:09 UTC](https://meta.discourse.org/t/rss-polling-may-take-20-minutes-and-more-to-process-a-feed/412322/14 "2026-09-18T12:09:13Z")

</div>


