search

atlassian-api / atlassian-python-api

Atlassian Python REST API wrapper
https://atlassian-python-api.readthedocs.io
Apache License 2.0
1.29k stars 642 forks source link

Rate limits applied on instance - our code borked #1289

Open GanizaniSitara opened 5 months ago

GanizaniSitara commented 5 months ago

Our infra team have switched on rate limits on our instance (no issues with that, right thing to do), but consequently our publishing code is borked. What do people do? Monkey patch the Atlassian library with a rate limit handler? Are there any 'proper' approaches to this? Thanks!

gonchik commented 5 months ago

@GanizaniSitara we can try to add retry for 429 error code

GanizaniSitara commented 5 months ago

That would be amazing. There's a recommended back-off pseudo code published by Atlassian here https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ I started to implement it only to realize I'm essentially rewriting your wrapper ...

mmahacek commented 5 months ago

This seems like a duplicate of #986. I've been occassionally getting a 429 rate limit when calling atlassian.Jira.user_find_by_user_string(). It would be nice if this could handle the backoff and retry within that method.

GanizaniSitara commented 5 months ago

Hi @mmahacek, yes it seems that way, I've only been made aware of the "Retry-After" headers by our support team in the last couple of days and haven't explored them yet. I had been thinking about he behaviour of the library - I think I would want to log a warning (as opposed to error) for the 429s and retry? But happy to be persuaded otherwise. Also there seem to be two types of limits with different behaviour which I saw after putting in my rudimentary rate limit wrapper. One is "rate limit" and the other is "too many messages" - that one seems to return a body with the response. I guess that might depend on how the instance is configured. Just something to flag for anyone testing this.