The problem with ignoring this error with something like:

if e, ok := err.(*Error); ok && e.ProblemType == "urn:ietf:params:acme:error:orderNotReady" {
	// ignore error if valid
}

is that we don't have the order to fetch the certificate. CreateOrderCert doesn't have the order's URI to re-fetch the order's status, so should this be up to the caller do handle this?

CC @rolandshoemaker, @x1ddos, @FiloSottile per owners.

Let's Encrypt will only set the status of an order to 'valid' if the certificate has already been issued. It's plausible if you are doing parallel validations of identical name sets you may be running into orders that are being reused at the server side. Are you checking if Order.CertURL is not empty if WaitOrder returns an order with a 'valid' status?

Oh sorry I misread the initial issue. This seems like expected behavior, if WaitOrder returns a valid order you should be using FetchCert rather than CreateOrderCert.

@rolandshoemaker I'm not doing parallel validations or fetches. I'm doing validations and then calling CreateOrderCert. Before calling CreateOrderCert the order is not valid. My current theory is that the issue is CreateOrderCert is internally retrying the authorization call but not realizing that the "error" ("Order's status ('valid') is not acceptable for finalization") on the second invocation is an okay response.

Also, to clarify, this seems like an edge case, we've been using the same code in production for close to a year and just ran into this problem last week a few times and it has since stopped happening.

CreateOrderCert doesn't do anything fancy, all it does is POST the finalization request, poll for the order status to change to 'valid', and fetch the resulting certificate. You will only get the 'wrong status' error if a. you've already called CreateOrderCert for the finalization URL before, or b. there is an issue on Let's Encrypt's end in computing order statuses.

Note that if you are creating two orders with the same set of names Let's Encrypt will reuse the order which would cause this exact problem (this is regardless of the CSR you use in CreateOrderCert). For example if you try to create two orders for ["example.com", "b.example.com"] before calling CreateOrderCert on the first order then Let's Encrypt will return the same order object, so you'll only be able to call CreateOrderCert once, the second time will return the error you are seeing as the order will have already been finalized.

CreateOrderCert doesn't do anything fancy, all it does is POST the finalization request, poll for the order status to change to 'valid', and fetch the resulting certificate.

I see inside of the POST for the finalization request that it has some retry logic. Is there any way I can debug what happened in there for future occurrences?

Oh hrm, I guess another possible explanation here is that LE is timing out internally, causing a 500 status code to be returned to the client but still actually completing the issuance. Since we receive a 500 we retry the call, resulting in the unexpected status error because the finalization actually happened despite us never seeing it happen.

I'm still not sure adding a case to ignore the error and refetch the order is the correct solution to this problem, since it introduces a somewhat complex codepath that relies on matching against a textual error that is specific to Let's Encrypt's implementation. I think I'm still of the opinion this is better handled in user applications.