webprofusion
Retry-After header does not seem to be honored
While testing the order process today I noticed that the certificate request timed out within 30 seconds after hitting finalize despite the ACME server indicating a Retry-After value of 5 in it's header and the order status still being 'processing'. While digging in the code I saw 10 attempts will be made and, if the Retry-After header is set, it will delay each task attempt by the given value. It should then be impossible to time out after only 30 seconds when the Retry-After header is set to 5 right?
Now I didn't dive into Anvil but is it possible that the 'RetryAfter' value isn't properly propagating and simply isn't set?
For further context, when looking at AnvilACMEProvider.cs and it's usage of orderContext.RetryAfter I do not see how Anvil's OrderContext, and specifically Anvil's EntityContext , has it's RetryAfter property set, if ever.
Hi, thanks for raising this issue. Currently the retry logic is split across the provider and the anvil library with some retries happening based on Retry-After, but not universally. There's also a need for some upper limit because if a server says retry after 5 minutes we should quit the order and just try again later rather than actually sleep for 5 minutes, as our renewal checks have a 5minute resolution anyway.
We do need to improve this but in the meantime if you have a slow ACME service you can work around that by setting DefaultACMERetryInterval in C:\ProgramData\certify\appsettings.json to a value like 30 (meaning 30 seconds wait between ACME operation retries), the default is only a few seconds wait between retries.
Our of interest what ACME service was this (or if internal, which ACME server software).
