Code to automatically retry requests which have a 429 or 500 error code was introduced in e4e8bde.
However, this code resubmits the exact same request, including the exact same anti-replay nonce header. This means that the first retry will always be rejected by the ACME server with a badNonce error and HTTP code 400, which then breaks out of the retry loop (because it is neither a 429 nor a 5xx).
At Let's Encrypt we see this in our logs: clients with the node-acme-client/5.4 user-agent which receive a 429 response immediately retry with the same nonce, get a 400 badNonce error, retry with a new nonce, get another 429, retry that with the same nonce, get a 400, rinse and repeat.
Please update node-acme-client to always use a new nonce when retrying, no matter whether the retry is due to a client error or a server error. This will result in a better experience for your users, and reduce unnecessary traffic to Let's Encrypt's API. Thanks!
Code to automatically retry requests which have a 429 or 500 error code was introduced in e4e8bde.
However, this code resubmits the exact same request, including the exact same anti-replay nonce header. This means that the first retry will always be rejected by the ACME server with a
badNonceerror and HTTP code 400, which then breaks out of the retry loop (because it is neither a 429 nor a 5xx).At Let's Encrypt we see this in our logs: clients with the
node-acme-client/5.4user-agent which receive a 429 response immediately retry with the same nonce, get a 400 badNonce error, retry with a new nonce, get another 429, retry that with the same nonce, get a 400, rinse and repeat.Please update node-acme-client to always use a new nonce when retrying, no matter whether the retry is due to a client error or a server error. This will result in a better experience for your users, and reduce unnecessary traffic to Let's Encrypt's API. Thanks!