Doesn't retry POST requests with 429 error status
Opened this issue · 1 comments
The default retryCondition isNetworkOrIdempotentRequestError only retries for 429 rate limiting when the request type is one of IDEMPOTENT_HTTP_METHODS, but ideally 429 means that the request was rejected without starting the execution so it should be safe to retry.
Using code in this comment as a work-around for now.
I completely understand your frustration—I'm also in a situation where I need to make batch requests with the POST method to external APIs, so thanks a lot for your workaround!
That said, I can also appreciate the intent of the library's authors here. The decision to restrict retries to idempotent methods is a reasonable safety measure, especially when dealing with potentially costly operations. Additionally, the fact that the retryCondition option allows for customization, and that isNetworkOrIdempotentRequestError is exposed, offers a manageable way to override the default behavior when needed. In that sense, the approach feels quite rational.
However, I agree with you that the limitation on retries to idempotent methods is under-documented. It’s buried within the retryCondition parameter’s description, which isn’t intuitive. I set up the library this morning, went through the README, and even dove into the source to adjust the retryDelay, but I hadn’t noticed this particular restriction until encountering it here. More explicit documentation in the README would go a long way in improving developer experience and clarifying behavior expectations upfront.