[Server] Serve ClientGateway::elicit() under the modern lifecycle (#466)
One handler asks the user something on any revision now. Where the client can be asked mid-request it still is; where it cannot, the ask becomes the input_required result that revision carries and the same call returns the answer once the client re-sends it. Costs one handler entry per ask, so side effects belong after the last question. Answers from earlier rounds travel in the requestState, which is why asking more than once needs Builder::setRequestState(). sample() and listRoots() still raise a LogicException there: that revision removed them outright.
This commit is contained in:
parent
0cd5d56164
commit
e0b9c1a26f
1 changed files with 700 additions and 117 deletions
|
|
@ -33,9 +33,9 @@ instead.
|
|||
call, and sending notifications.
|
||||
* **[Logging](logging.md)** — structured PSR-3 log messages that surface in the client,
|
||||
not in your server's log file.
|
||||
* **[Asking for input](input-required.md)** — returning an `InputRequiredResult` when a
|
||||
handler needs elicitation, sampling or roots. Written that way, one handler serves both
|
||||
[protocol eras](../protocol-versions.md).
|
||||
* **[Asking for input](input-required.md)** — `ClientGateway::elicit()`, or returning an
|
||||
`InputRequiredResult` when a handler needs several answers at once. Either way, one
|
||||
handler serves both [protocol eras](../protocol-versions.md).
|
||||
|
||||
Handlers that need application services (a database connection, an API client) get them
|
||||
from the container instead; see
|
||||
|
|
|
|||
Loading…
Reference in a new issue