Recently we started running into the following error with increasing frequency:
Acme::Client::Error::UnsupportedOperation: Directory at https://acme-v02.api.letsencrypt.org/directory does not include `new_order`
/usr/src/app/lib/acme/client/resources/directory.rb:27:in `block in endpoint_for'
/usr/src/app/lib/acme/client/resources/directory.rb:26:in `fetch'
/usr/src/app/lib/acme/client/resources/directory.rb:26:in `endpoint_for'
/usr/src/app/lib/acme/client.rb:357:in `endpoint_for'
/usr/src/app/lib/acme/client.rb:131:in `new_order'
The line numbers in directory.rb can't be trusted, because they come from a patched version of same. We guessed that directory.rb was ignoring the fact that it had received an API error, so we instrumented it to include the HTTP response as a custom property on the UnsupportedOperation.
Here is what we got:
HTTP 403
{"type": "urn:ietf:params:acme:error:rateLimited", "detail": "Your IP, x.x.x.x, has been blocked due to extremely high traffic. Once corrected, request a review by emailing unblock-request@letsencrypt.org"}
Looks like the at least the error detection aspect of the Faraday middleware should be applied to directory ops?
Recently we started running into the following error with increasing frequency:
The line numbers in
directory.rb
can't be trusted, because they come from a patched version of same. We guessed thatdirectory.rb
was ignoring the fact that it had received an API error, so we instrumented it to include the HTTP response as a custom property on theUnsupportedOperation
.Here is what we got:
Looks like the at least the error detection aspect of the Faraday middleware should be applied to directory ops?