RFC 8555 s. 7.1.6 states
Challenge objects are created in the "pending" state. They
transition to the "processing" state when the client responds to the
challenge (see [Section 7.5.1](https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1)) and the server begins attempting to
validate that the client has completed the challenge. Note that
within the "processing" state, the server may attempt to validate the
challenge multiple times (see [Section 8.2](https://datatracker.ietf.org/doc/html/rfc8555#section-8.2)).
[...]
pending
|
| Receive
| response
V
processing <-+
| | | Server retry or
| | | client retry request
| +----+
|
|
Successful | Failed
validation | validation
+---------+---------+
| |
V V
valid invalid
State Transitions for Challenge Objects
However, challenges never transition from pending to processing. They remain pending until they're either updated to 'valid' or 'invalid'.
Expectation: Upon immediate subsequent post-as-get of the authorization or challenge, both would show the challenge state as 'processing'. (Also maybe with the expectation of 'processing' in the response to posting {} to the challenge URL. By comparison, Google returns 'proessing' for this step, but immediately transitions to 'processing' in a PaG just after.)
Note: Testing was done in LE staging and not prod.
RFC 8555 s. 7.1.6 states
However, challenges never transition from pending to processing. They remain pending until they're either updated to 'valid' or 'invalid'.
Expectation: Upon immediate subsequent post-as-get of the authorization or challenge, both would show the challenge state as 'processing'. (Also maybe with the expectation of 'processing' in the response to posting {} to the challenge URL. By comparison, Google returns 'proessing' for this step, but immediately transitions to 'processing' in a PaG just after.)
Note: Testing was done in LE staging and not prod.