Rate limits applied on instance - our code borked

[GanizaniSitara]

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]

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

[GanizaniSitara]

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]

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]

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.