Retry mechanism behaves incorrectly when HTTP 429 is returned by Datadog
Mantenedores costumam responder em até 2 dias
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 3/5
- Tempo estimado
- 1-2 dias
- Facilidade para iniciantes
- 45/100
Direção de pesquisa
Comece rastreando como a opção enable_retry trata as respostas HTTP 429 no cliente, usando a sequência de busca do dashboard e os testes relacionados a novas tentativas descritos na issue. Reproduza o caso de limite de taxa e verifique se o cliente aguarda x-ratelimit-reset antes de tentar novamente, em vez de sair ao receber o primeiro 429.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Describe the bug
Summary:
Script which fetches all dashboards in the loop exits with an error, when rate limit runs out, even though enable_retry option is turned on. According to debug logs, script exits on first HTTP 429 returned, with no retry attempted.
Details:
We have a script, which runs every night to fetch all dashboards from Datadog. It does it by fetching list of dashboards, and then goes one after another to fetch details of each one. After number of our dashboard grew, we have run into HTTP 429 errors due to Datadog's rate limit.
We decided to use retry option, which is built into the library since 2.16.0, but it seems it's not ready to how Datadog responds in case of hitting rate limit.
When I started the script in a loop with debug option enabled I see that Datadog returns HTTP 200 up until the moment when rate limit is reached, then next request gets HTTP 429 (API Keys removed from logs below):
# normal request before rate limit runs out
send: b'GET /api/v1/dashboard/<id-of-dashboard-59> Host: us5.datadoghq.com Accept-Encoding: gzip User-Agent: datadog-api-client-python/2.23.0
reply: 'HTTP/1.1 200 OK'
...
header: content-encoding: gzip
header: x-ratelimit-limit: 60
header: x-ratelimit-period: 60
header: x-ratelimit-remaining: 1
header: x-ratelimit-reset: 29
header: x-ratelimit-name: dashboards_get_custom_api
# normal request, last one within the limits
send: b'GET /api/v1/dashboard/<id-of-dashboard-60> Host: us5.datadoghq.com Accept-Encoding: gzip User-Agent: datadog-api-client-python/2.23.0
reply: 'HTTP/1.1 200 OK'
...
header: content-encoding: gzip
header: x-ratelimit-limit: 60
header: x-ratelimit-period: 60
header: x-ratelimit-remaining: 0
header: x-ratelimit-reset: 28
header: x-ratelimit-name: dashboards_get_custom_api
# next request, this one gets HTTP 429
send: b'GET /api/v1/dashboard/<id-of-dashboard-61> Host: us5.datadoghq.com Accept-Encoding: gzip User-Agent: datadog-api-client-python/2.23.0
reply: 'HTTP/1.1 429 Too Many Requests'
...
header: x-ratelimit-limit: 60
header: x-ratelimit-period: 60
header: x-ratelimit-remaining: 0
header: x-ratelimit-reset: 28
header: x-ratelimit-name: dashboards_get_custom_api
# and at this point script fails with
Error: (429)
Reason: Too Many Requests
HTTP response headers: {'x-ratelimit-limit': '60', 'x-ratelimit-period': '60', 'x-ratelimit-remaining': '0', 'x-ratelimit-reset': '28', 'x-ratelimit-name': 'dashboards_get_custom_api', 'content-type': 'application/json', 'Content-Length': '183', 'x-content-type-options': 'nosniff', 'strict-transport-security': 'max-age=31536000; includeSubDomains; preload', 'date': 'Mon, 25 Mar 2024 09:05:32 GMT', 'Via': '1.1 google', 'Alt-Svc': 'h3=":443"; ma=2592000,h3-29=":443"; ma=2592000'}
HTTP response body: {'status': 'error', 'code': 429, 'errors': ['Too many requests'], 'statuspage': 'http://status.us5.datadoghq.com', 'twitter': 'http://twitter.com/datadogops', 'email': '[email protected]'}
To Reproduce
See description above
Expected behavior
I expect library to sleep for x-ratelimit-reset time, just like it's described in tests, which introduced this functionality. Right now I need to add a sleep between requests to API as a workaround
Screenshots
N/A - logs attached
Environment and Versions (please complete the following information):
client library version 2.23.0
Additional context
Add any other context about the problem here.
- Linguagem predominante
- Python
- Estrelas
- 167
- Forks
- 55
- Merge médio
- 2d 23h
- PRs com merge (30d)
- 74
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de DataDog/datadog-api-client-python
-
Python 3.13/3.14 SyntaxWarning in v1 LogsPipelinesApi docstringTalvez já em andamento @Mirochill assumiu há 143 dias. Abertastale
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 72/100
DataDog/datadog-api-client-python#3535 · 1 comentário ·
Mantenedores costumam responder em até 2 dias
-
kind/bug stale
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 66/100
DataDog/datadog-api-client-python#3717 · 3 comentários ·
Mantenedores costumam responder em até 2 dias
-
kind/bug stale
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 75/100
DataDog/datadog-api-client-python#3656 · 1 comentário ·
Mantenedores costumam responder em até 2 dias
-
kind/bug stale
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 38/100
DataDog/datadog-api-client-python#3120 · 1 comentário ·
Mantenedores costumam responder em até 2 dias
-
stale
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
DataDog/datadog-api-client-python#2986 · 1 comentário ·
Mantenedores costumam responder em até 2 dias
Todas as issues de DataDog/datadog-api-client-python
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
good first issue No-AI
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 69/100
-
documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
-
🐛 Bug: Calendar work items cannot be opened on mobileTalvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 75/100
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 2 dias