The visitor experience, named rather than left to whoever writes the shim.
A form POST whose validator needs a deferred verification has exactly three honest options, and
only one of them is not broken:
Reject the submission. The visitor passed the captcha and is told they failed. Never.
Block the render until the alarm drains. Impossible: the run is synchronous.
Re-submit once, automatically. The validator queues the verification, marks the form
"awaiting verification", and the response re-posts the same form after retryAfterMs. The
second submission finds the result cached and completes.
Three is what this returns. The visitor sees one extra round trip on submit and no error. The
added latency is one alarm cycle plus one HTTP round trip -- a WALL-CLOCK quantity, and per RULE 0
no CPU figure can be derived from it.
The token survives the round trip because the SAME token is re-posted: the key is the exact
tuple, so the second submission hits the entry the first one queued. A shim that minted a new
token on re-submit would miss the cache every time and loop forever, which is the one way to get
this wrong.
The visitor experience, named rather than left to whoever writes the shim.
A form POST whose validator needs a deferred verification has exactly three honest options, and only one of them is not broken:
retryAfterMs. The second submission finds the result cached and completes.Three is what this returns. The visitor sees one extra round trip on submit and no error. The added latency is one alarm cycle plus one HTTP round trip -- a WALL-CLOCK quantity, and per RULE 0 no CPU figure can be derived from it.
The token survives the round trip because the SAME token is re-posted: the key is the exact tuple, so the second submission hits the entry the first one queued. A shim that minted a new token on re-submit would miss the cache every time and loop forever, which is the one way to get this wrong.