API-Rate-Limit bei der Kategorieerstellung ändern/entfernen

Ich habe ein Problem beim Erstellen von Kategorien über die API. Es scheint ein Limit zu geben, das weder anpassbar ist noch eine Einstellung zum Deaktivieren hat.

Die Fehlermeldung lautet: „Wir haben ein tägliches Limit, wie oft diese Aktion ausgeführt werden kann. Bitte warten Sie 17 Sekunden, bevor Sie es erneut versuchen."

Die angegebene Sekundenanzahl liegt zwar immer unter 20, ist aber nie genau, da es sich angeblich um ein tägliches Limit handelt. Ich habe es auch innerhalb einer Minute nach dem letzten Versuch erneut versucht. Außerdem habe ich ALLE Rate-Limits im Admin-Dashboard auf 1000+ erhöht, aber keines davon scheint sich auf die Kategorieerstellung auszuwirken.

Die einzigen verfügbaren Rate-Limits im Dashboard sind: maximale Themen, private Nachrichten, Likes, Lesezeichen, Flaggen, Bearbeitungen, Einladungen, Themen-Einladungen, Themen, Drucke und Anmeldungen.

Ich verwende dafür GitHub - discourse/discourse_api: Ruby API for Discourse · GitHub, was bis zum Erreichen des nicht spezifizierten Rate-Limits einwandfrei funktioniert hat.

Habe ich etwas übersehen? Dies kommt nicht von nginx, da die Meldung von Discourse stammt und das Rate-Limiting-Template für nginx deaktiviert wurde.

See:

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 ^^^

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 receiving?

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.

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.

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: