Query regarding rate limits during serverInternal error

[santhoshmanikandan]

On 10th June(around 6 AM - 7 AM in GMT), few new order requests for auto-renewal of certificates failed in our custom LE client with the following error.

Error: Error Status : 500
Error type : urn:ietf:params:acme:error:serverInternal
Error detail : Error creating new order

After few failures, the response changed to rate limit error.

Error creating new order :: too many currently pending authorizations: see Rate Limits - Let's Encrypt

Can someone reply to the following queries?

1. Will the domains that were present in the failed order requests are accounted for the pending authorization count as I don't see any other failures during that time period?
2. We do store the order url returned in order request on a successful response for reuse. But in a failure case, I am not sure whether the order url is available in the header as the order url is added only if order creation is successful. Correct me if I am wrong and kindly share whether the order url can be fetched from header even during failure response.

Let me know if you need more information for the same.

[webprofusion]

@santhoshmanikandan

urn:ietf:params:acme:error:serverInternal

Your errors were potentially when the API was being updated: Let's Encrypt Status

I'm guessing someone from LE has to clear these or you just have to wait for the rate limit to clear.

[santhoshmanikandan]

@webprofusion

I'm guessing someone from LE has to clear these or you just have to wait for the rate limit to clear.

Yeah, that's fine. But I raised this question to check whether server internal error during new order requests is considered for pending authorization domain count at LE end. If it's so, shouldn't domains in failed order response be skipped in rate limit check as the client doesn't have control over this situation?

[webprofusion]

Yes, I would agree if the order fails it shouldn't have any pending authorizations, but I don't know enough about Boulder to say how it handles such things.

Given that the pending auth limit is 300 I'd suggest that when failure happens you limit your number of retries.

[aarongable]

At this time, we do not make many guarantees about the state of the service when you receive a 500 error response. That error could have occurred at any point during request processing: at the very beginning, before we have even looked up the account ID from the JWS; at the very end, after all of the relevant database updates have been made; or anywhere in between. If the relevant database updates have been made, then yes, the request has consumed part of your rate limit. It is unfortunate that it consumed rate limit without getting you a usable response, but this is why we monitor our services to keep 500s to a minimum.

As @webprofusion said; I suggest that your custom client implement exponential backoff when encountering errors to prevent this situation.