Random failures and erroractionpreference causing other scripts to fail

[BRT917]

Random failures and erroractionpreference causing other scripts to fail

[glatzert]

Could you take a look into the error details and provide them?
Essentially the IsError should only be true for HttpStatus Codes (returned from Let's Encrypt) > 400. Which normally means something went wrong, and we've no way to recover or do something useful afterwards.
That's why it issues an terminating error.

If you want to just try again, you can catch it with try {} catch {}.

Changing the throw to write-error, would not terminate the currently running function and would end up in more errors being thrown.

[BRT917]

Error:
Server returned problem (Status: 400).
@{type=urn:ietf:params:acme:error:badNonce; detail=JWS has an invalid anti-replay nonce:
"0102awhAU9D2anavAc277bLVzM5Sfl-OIS0k22BFWkl_Atfk"; status=400}
At C:\Program Files\WindowsPowerShell\Modules\acme-ps\1.1.2\ACME-PS.psm1:1183 char:13
throw "$($response.ErrorMessage)"n$($response.Content)";
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Server returned...k"; status=400}:String) [], RuntimeException
+ FullyQualifiedErrorId : Server returned problem (Status: 400).
@{type=urn:ietf:params:acme:error:badNonce; detail=JWS has an invalid anti-replay nonce: "0102awhAU9D2anavAc277bLVz
M5Sfl-OIS0kk22BFWkl_Atfk"; status=400}

If I try it again a few times with the same state and nonce it eventually goes through fine.

my thoughts on using a throw instead of write-error is that a throw doesn't seem to respect erroractionpreferences set by a script calling the module where a write-error would. i.e. It'd be better to give the user the decision on how to handle errors rather than deciding for them.

Edit: a try/catch should be able to get around it as is, but it seems real unnecessary to do it for every single acme-ps related command in a large script, I guess i'm just being a bit lazy here

[glatzert]

Ah sorry, I was talking nonsense before.
The Response will report an error for everything HttpStatus >= 400.
Furthermore it'll extract a given nonce, if any and set that to the acme-state, so it's kind of self-healing.
Essentially (if you do not some kind of multi-session or multi-threading) the nonce should be okay with the next call.

The throw is used, because the functions normally won't end with calling Let's Encrypt, but will also use the result - that might be "lazy" on my side, because I did not want to use -errorAction 'Stop' everywhere. Also, your script probably cannot go on if such an error occures as well.

To relieve the problem, it'd be possible to use the problem-type (urn:ietf:params:acme:error:badNonce) to detect a faulty nonce and automatically retry with a new one. The detection could be done in AcmeHttpResponse and Invoke-SignedWebRequest could manage (a single) retry.

[glatzert]

I included an automatic retry on nonce error.
Also you can now get the error details from the thrown exception.
Will be available in 1.1.3 once it's in the gallery. If you like to get a head start, try the beta ;).