Changing/removing API rate limit with category creation

I’ve been running into an issue with creating categories via the API. It seems there is a limit, but that limit doesn’t seem to be customizable nor does it seem to have a setting to disable it anywhere.

The error I get is: We have a daily limit on how many times that action can be taken. Please wait 17 seconds before trying again.

The amount of seconds seems to always be under 20 seconds, but never accurate as it states that it is a daily limit and I’ve tried within a minute of the last attempt. I’ve also tried adjusting ALL rate limits under the admin dashboard to 1000+, but none of them seem to affect category creation.

The only available rate limits on the dashboard: max topics, private messages, likes, bookmarks, flags, edits, invites, topic invitations, topics, prints, and logins.

I’m using the GitHub - discourse/discourse_api: Ruby API for Discourse for it, which worked fine until the unspecified rate limit was hit.

Am I missing something? This isn’t coming from nginx either, as the message is from Discourse and the rate limiting template for nginx has been disabled.

See:

3 Likes

Thanks @sam, not sure how I missed that!

No worries, I have meant to make that post for a while @mpalmer asked for it a few weeks ago ;p

@community FYI ^^^

3 Likes

Ahh, it’s new, didn’t notice that either. Not on top of it today I guess…

I’m only performing one request though to create a category and don’t see any daily limits there. Is there another limit that would be attributing to the 429 error?

Well first thing I would try is another API endpoint to see if this is the global rate limit or some specific rate limit on category creation (or maybe a user rate limit in the app), be sure your api_username is an admin

Using ‘system’ and the key was generated via the admin dashboard. It don’t have an issue grabbing the category list, only creating a category.

Not seeing anything particular in the app, I would try a different admin user to see what happens, maybe the error you are getting is a different limit.

Tried another user and a generic key for all users, but both hit the same 429 error and limit when trying to create a category.

Is there anything in the response body you are getting.

Just the error message:

 {"errors"=>["We have a daily limit on how many times that action can be taken. Please wait 21 seconds before trying again."], "error_type"=>"rate_limit"} (DiscourseApi::TooManyRequests)

Are you 100% sure nothing is stuck in some sort of a loop hitting the server?

Also are you running latest version of Discourse?

Does it come back with 21 seconds every time?

Running 2.0.0.beta1. Not aware of anything looping, only I have access to these keys and the script that runs them is ran manually by me as I’m developing something to automate creating categories. I have 1 call to get the existing category lists, then one call per category creation (only 1 category right now). It has worked to create most of the categories before the rate limit got hit.

The ‘seconds’ varies; often 12, 17, 21, or other amount around that amount.

What happens if you disable the global admin api rate limit (raise it to say 500 a minute and 500 per ten seconds)? Does this go away?

I would guess that something about your script is pummeling too many requests at the server.

5 Likes

Yup… you appear to have been right! A variable wasn’t being set when it needed to be, so it was bypassing a check I had. Seems to be working fine now, no hammering the API anymore. Still good to know the info you posted though, so I appreciate that.

5 Likes

Hey @sam, could you point me to where I can disable the global admin api limit? I have a script to pull response times that requires getting all the topics in a timeframe and then for each topic, getting all of the posts for the topic, and I keep running into the rate limiting (You’ve performed this action too many times. Please wait 6 seconds before trying again.').

Apologies if this old thread i dug up is now really out of date :smiley:

Are you 100% sure it is not covered in:

1 Like