What a caller should do with a deferred request right now.
This is the fourth problem and the one that decides whether the feature is usable: the first
request cannot have the answer. The queue drains on an alarm, so the synchronous read on the
first attempt necessarily misses.
The states are deliberately few, because the Drupal-side shim has to act on them inside a form
validator with no ability to wait:
miss nothing queued; queue it and tell the caller to come back
pending queued, not yet drained; come back
ready a fresh result is available; consume it
expired a result existed and is too old to mean anything; re-queue rather than serve it
failed the attempt budget is spent; this is a definite no, not a "try again"
failed being distinct from pending is what stops a form retrying forever against an endpoint
that is down.
What a caller should do with a deferred request right now.
This is the fourth problem and the one that decides whether the feature is usable: the first request cannot have the answer. The queue drains on an alarm, so the synchronous read on the first attempt necessarily misses.
The states are deliberately few, because the Drupal-side shim has to act on them inside a form validator with no ability to wait:
missnothing queued; queue it and tell the caller to come backpendingqueued, not yet drained; come backreadya fresh result is available; consume itexpireda result existed and is too old to mean anything; re-queue rather than serve itfailedthe attempt budget is spent; this is a definite no, not a "try again"failedbeing distinct frompendingis what stops a form retrying forever against an endpoint that is down.