User Ethsim2 reported an issue where the FullCalendar v6 plugin on a self-hosted Discourse instance exhibited unexpected rate-limiting behavior, specifically failing to load events when navigating to future weeks. Despite configuring high custom rate limits in app.yml, the user observed that events loaded in large chunks and then stopped, requiring page refreshes. The issue appeared after recent rebuilds and was initially suspected to be related to undocumented internal rate limiters or the MAX_RESULTS setting. j.jaffeux requested reproduction details, leading Ethsim2 to provide commit hashes and screen recordings showing the UI stalling rather than returning HTTP 429 errors. The problem appeared to resolve temporarily after updating Discourse by 20 commits, only to recur later. By March 2026, Ethsim2 noted that while the FullCalendar UI issue seemed resolved, rate limiting shifted to the /discourse-post-event/events.ics export endpoint. A workaround was identified using webcal:// URLs with ?after=DATE parameters to limit exported event windows, confirming the endpoint supports date-windowed exports. sam questioned if any issues remained, to which Ethsim2 confirmed that testing on multiple themes and VPS instances with version 2026.3.0-latest.1 showed the FullCalendar functionality was fully restored.
After a recent Discourse rebuild (self-hosted), I am consistently encountering user-facing rate limiting when viewing the main Full Calendar Version 6, even though my site has very low activity (1–2 simultaneous users). This behavior started appearing after my last two rebuilds.
Confirm if there are any new or hidden rate limiters that would affect background or plugin-generated requests after a recent update/rebuild, and if so, describe how to override or tune them.
Advise why my high custom rate limits are not being respected for the calendar view.
Suggest further troubleshooting or configuration changes, if any.
It looks like this could be related to Re-add full ics export - #9 by kelv because 100 events seem to show, then after about 2 minutes can display another large batch, and they don’t appear gradually but in large chunks.
Edit: This rate-limited behaviour is manageable for now, but becomes apparent when advancing far; i can see all the events for my current week and all the events in the next, it’s if i then proceed to the next week i hit the hard limit.
I should also clarify that, the upcoming events full calendar v6 wasn’t rate limited to this extent, before i set the custom api throttle settings. These app.yml settings didn’t change the rate limiting visible on FullCalendar
i don’t think it’s that kind of rate limit. When i mentioned API throttle settings, i really meant my Discourse is configured to handle many event topics, but FullCalendar view is not working as well as it used to before the code was merged
Apologies for the confusion
Edit: i have edited the OP to reflect the lack of 429 errors
I am on the latest versions. From a UI perspective, this problem fixed itself overnight. I updated last night but problem didn’t fix itself immediately. The total number of events that have passed is about 270. I have now changed back to using PWA…
my Discourse instance is up to date with tests-passed. I had a report from a seperate user of my instance yesterday that a future week view wasn’t loading all the events. Having already noticed that this error ceased to affect UI of the Current week view, i tried to pinpoint the error on my Laptop. Below is the video re-production;
the same “lack of events” in a future week, can be re-produced the same on my Smartphone
i’m getting this error in browser console after about a minute of opening discourse, it deosn’t seem to have an effect on my upcoming events page. Refreshing the upcoming events page deosn’t reproduce the error, the error was found in loading homepage
