Alterando/removendo limite de taxa de API com criação de categoria

Tenho enfrentado um problema ao criar categorias via API. Parece haver um limite, mas ele não parece personalizável, nem há nenhuma configuração para desativá-lo em lugar algum.

O erro que recebo é: Temos um limite diário para quantas vezes essa ação pode ser realizada. Aguarde 17 segundos antes de tentar novamente.

O número de segundos parece ser sempre inferior a 20 segundos, mas nunca é preciso, já que a mensagem afirma ser um limite diário e eu tentei dentro de um minuto após a última tentativa. Também tentei ajustar TODOS os limites de taxa no painel administrativo para 1000+, mas nenhum deles parece afetar a criação de categorias.

Os únicos limites de taxa disponíveis no painel são: tópicos máximos, mensagens privadas, curtidas, marcadores, denúncias, edições, convites, convites para tópicos, tópicos, impressões e logins.

Estou usando a biblioteca GitHub - discourse/discourse_api: Ruby API for Discourse · GitHub para isso, que funcionou bem até atingir o limite de taxa não especificado.

Estou esquecendo algo? Isso não está vindo do nginx, pois a mensagem é do Discourse e o modelo de limitação de taxa para o nginx foi desativado.

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: