Error 429 Too Many Requests when use rule "Watchlisted by"

[TuGeek]

Describe the bug When I use the "Watchlisted by" rule it sometimes gives the following error:

• hostname: 'community.plex.tv'
• port: 443
• statusCode: 429
• statusMessage: 'Too Many Requests'

And restarts the entire application.

To Reproduce Use the "Watchlisted by" rule.

Expected behavior It should work without any problem and not overload the requests.

Screenshots

Device (please complete the following information):

• OS: Docker
• Version 2.1.0

[jorenn92]

Does this issue occur shortly after rule handling begins? Do you have any users with large watchlists?

I’ve been investigating the cause, and one explanation is that Maintainerr might be cycling through the API pages too quickly. However, this should only happen if a user has a significant number of watchlisted items, as each page contains 50 items. Once all the pages are processed, they’re cached for 10 minutes, so subsequent calls shouldn’t trigger the issue again—at least not for the next 10 minutes.

Another possibility could be that we're overloading the API when you have a large number of users, as we need to fetch the watchlist for each server user. How many users do you have?

Plex's community API is undocumented, so i actually don't know how many calls we're able to make per hour. That's one reason why the rule is marked as 'experimental'

[TuGeek]

Does this issue occur shortly after rule handling begins? Do you have any users with large watchlists?

I’ve been investigating the cause, and the only explanation I can think of is that Maintainer might be cycling through the API pages too quickly. However, this should only happen if a user has a significant number of watchlisted items, as each page contains 50 items. Once all the pages are processed, they’re cached for 10 minutes, so subsequent calls shouldn’t trigger the issue again—at least not for the next 10 minutes.

The problem occurs shortly after starting the scan, and it is possible that there is someone with a huge Watchlist.

For reference, the Watchlistarr project (https://github.com/nylonee/watchlistarr) uses different methods to obtain users' watchlists and I have not had any problems using it.

Thank you very much for your work, I just discovered the project and it is incredible.

[jorenn92]

Thanks for the kind words!

I took a quick look at Watchlistarr, and it appears they’re using a combination of RSS feeds and a similar community API call to fetch IDs. However, they’re using a limit of 100 items per call, instead of 50. This significantly reduces the number of calls and might help avoid the issue. I’ll try increasing the limit to 100 as well, and hopefully, that will be enough to resolve it.

[TuGeek]

Sorry, I didn't tell you the number of users before. I have 50 users, which may also have an effect on whether the call has to be made for each user.

I'll send you the complete log in case it can be of help to you, and if you need me to try something else, I'm here to experiment. 😄 _maintainerr_logs.txt

[jorenn92]

Sorry, I didn't tell you the number of users before. I have 50 users, which may also have an effect on whether the call has to be made for each user.

I'll send you the complete log in case it can be of help to you, and if you need me to try something else, I'm here to experiment. 😄 _maintainerr_logs.txt

Thanks! I noticed from your log that the issue didn’t occur during the automatically scheduled rule handling jobs (every 8 hours), but rather when you manually triggered one. My suspicion now is that, since the previous rule handling job ran only an hour and 20 minutes earlier, the rate limits hadn’t reset yet, and we exceeded them by fetching all the watchlists again.

I’m not sure there’s much I can do, aside from minimizing the number of API calls by increasing the number of items per page and possibly extending the cache duration. However, I do need to ensure the server doesn’t crash when this issue occurs.

[jorenn92]

I’ve pushed a potential fix for the crashing issue in this pull request. While the rate limit will still be hit if rules are run too close together, it should now be logged and, hopefully, occur less frequently.

This'll be available on the develop / main Docker image in about 15 minutes. Are you by any chance able to try this out on your server?

[TuGeek]

I’ve pushed a potential fix for the crashing issue in this pull request. While the rate limit will still be hit if rules are run too close together, it should now be logged and, hopefully, occur less frequently.

This'll be available on the develop / main Docker image in about 15 minutes. Are you by any chance able to try this out on your server?

Of course, I take the development branch and start the service to test it.

Regarding what you say, I have indeed launched it manually to see that it works, I understand that once it is running with the cron it will make fewer calls, but in any case it will need a first load of all the watchlists.

I will tell you how the hotfix is ​​as soon as I have been able to test it.

[jorenn92]

I’ve pushed a potential fix for the crashing issue in this pull request. While the rate limit will still be hit if rules are run too close together, it should now be logged and, hopefully, occur less frequently. This'll be available on the develop / main Docker image in about 15 minutes. Are you by any chance able to try this out on your server?

Of course, I take the development branch and start the service to test it.

Regarding what you say, I have indeed launched it manually to see that it works, I understand that once it is running with the cron it will make fewer calls, but in any case it will need a first load of all the watchlists.

I will tell you how the hotfix is ​​as soon as I have been able to test it.

It’s not actually making fewer calls; it's doing the same amount. However, it seems that Plex’s community API endpoint has a limit on the number of calls within a certain timeframe (which appears to be longer than one hour). If we run the rule handler twice, with 15 minutes between runs, the cache won’t be used for the second job, meaning it will make all the API calls again.

So, if the first job makes 50 calls and the second job also makes 50, and Plex only allows, say, 90 calls per hour, we’ll exceed the limit during the second run.

[TuGeek]

It’s not actually making fewer calls; it's doing the same amount. However, it seems that Plex’s community API endpoint has a limit on the number of calls within a certain timeframe (which appears to be longer than one hour). If we run the rule handler twice, with 15 minutes between runs, the cache won’t be used for the second job, meaning it will make all the API calls again.

So, if the first job makes 50 calls and the second job also makes 50, and Plex only allows, say, 90 calls per hour, we’ll exceed the limit during the second run.

In that case, I'm going to activate a single rule that uses the "Watclisted by" function and let it run with the cron, and then I'll tell you how it worked.

[Adrian-Rasmussen]

maintainerr-2024-09-06.log It still seems to be crashing for me, running latest develop and manually running the rule. When left with the cron prior to updating, it didn't seem to update the collection but I don't have the logs for that currently.

I have 10 users, watchlist sizes vary from 0 to 90, most around 10-20.

[jorenn92]

maintainerr-2024-09-06.log It still seems to be crashing for me, running latest develop and manually running the rule. When left with the cron prior to updating, it didn't seem to update the collection but I don't have the logs for that currently.

I have 10 users, watchlist sizes vary from 0 to 90, most around 10-20.

I’ve created a new PR where I upgraded the Axios library to the latest version and tried to catch the error as early as possible. Hopefully, this resolves the issue—if not, I might need to log a bug with Axios.

It’s possible you hit the API limit during your first run. Besides increasing the chunk size, which I’ve already done, there’s not much more I can do for larger watchlists / many users. It would be helpful to know the exact API limits, but I’d need to dig deeper into that (which I might do if the problem continues).

[TuGeek]

I'm looking for alternatives to make the query, and I have found that the Overseerr API also stores the information of the user's Watchlist, with the difference that in Overseer the requests are made with the token of each user.

https://api-docs.overseerr.dev/#/users/get_user__userId__watchlist

Could it be another rule associated with Overseer? like "Overseer - [list] Watchlisted by (username)".

While we can continue experimenting on how to get the Watchlisted by list in Plex with many users.

[jorenn92]

I'm looking for alternatives to make the query, and I have found that the Overseerr API also stores the information of the user's Watchlist, with the difference that in Overseer the requests are made with the token of each user.

https://api-docs.overseerr.dev/#/users/get_user__userId__watchlist

Could it be another rule associated with Overseer? like "Overseer - [list] Watchlisted by (username)".

While we can continue experimenting on how to get the Watchlisted by list in Plex with many users.

That’s an option worth exploring, but I believe it would only work for users who have logged into Overseerr and possibly only for those who have the 'Import from Plex watchlist' option enabled. Ideally, I’d prefer a system that directly fetches the watchlist from Plex, though this could be a separate rule entirely. I don’t have the time to work on it right now, but I’m open to PRs if anyone wants to take it on.

[Adrian-Rasmussen]

I’ve created a new PR where I upgraded the Axios library to the latest version and tried to catch the error as early as possible. Hopefully, this resolves the issue—if not, I might need to log a bug with Axios.

Unfortunately it didn't, same crash maintainerr-2024-09-06.log

[jorenn92]

I’ve created a new PR where I upgraded the Axios library to the latest version and tried to catch the error as early as possible. Hopefully, this resolves the issue—if not, I might need to log a bug with Axios.

Unfortunately it didn't, same crash maintainerr-2024-09-06.log

Another attempt to improve the caching mechanism has been made in this pull request. The Axios error that’s causing the server to break seems to be a known issue that has existed for a while: axios/axios#5538 and axios/axios#3396.

[TuGeek]

Another attempt to improve the caching mechanism has been made in this pull request. The Axios error that’s causing the server to break seems to be a known issue that has existed for a while: axios/axios#5538 and axios/axios#3396.

This time, in my case it has worked perfectly. :+1:

Thank you so much!!

[jorenn92]

Another attempt to improve the caching mechanism has been made in this pull request. The Axios error that’s causing the server to break seems to be a known issue that has existed for a while: axios/axios#5538 and axios/axios#3396.

This time, in my case it has worked perfectly. 👍

Thank you so much!!

Great to hear! Hopefully it’s working for others as well.

[Adrian-Rasmussen]

Yes looks like it is working fine now for me as well, thanks!

[TuGeek]

With version 2.1.1 I'd say the issue is now resolved, so I'm closing it.

Thanks a lot for everything @jorenn92, once again, an amazing job.