Why an execution waits, what it holds and how it goes on
Which nodes put an execution down, what the request is answered with, what money is held during the wait, and how and when the execution goes on.
4 min read
An execution does not always run from the entry to the end in one go. At some nodes it stops, waits, and goes on by itself later. This page is about such a pause from the side of the flow: what puts an execution down, what it keeps, and what it holds while it waits.
What makes an execution wait
| Where it stops | What it waits for |
|---|---|
| Queue | The delay the node is set to |
| Require Approval | A decision of a person or a key, or the end of the time to decide |
| AI Model whose pool is set to wait | A connection of the pool that can take the call — after a rate limit, or when none has capacity left |
| AI Model whose provider runs the call in the background | The answer of the provider |
| AI Model whose overrun policy asks for approval | A decision on the approval |
A request sent in async mode waits as well, before any node runs: it is queued until a worker starts it at the entry node.
What the request is answered with
A request whose execution stops is answered at once with 202 and the status waiting. The answer says in waiting_on at which node the execution stands and what it waits for, and retry_after_seconds says when to read the status again. Async runs and waiting lists each reason of waiting_on and shows how an application waits for the result.
After a pause nothing answers the request any more: it has been answered. What the flow does next — its answer, a refusal, an error — is read from the status of the execution, or arrives with the execution.finished webhook.
What is kept and what is held
Slen keeps what the execution has gathered: the input, the context and the outputs of the nodes it passed, sealed until the execution goes on. Execution context and paths says what a node after the pause can read.
| The pause | What is held while it waits |
|---|---|
| Queue, Require Approval | Nothing. A model after the node is reserved for after the pause, against the budgets as they are then |
| A pool that waits for a connection | Nothing. The hold of the call that could not be made is given back; the call takes a new one when it is tried again |
| An overrun approval | Nothing. The hold is given back when the approval is raised |
| A call the provider runs in the background | The hold of the call, for 30 minutes from the start of the call by default. After that the hold is given back while Slen still asks for the answer, and a late answer is captured late |
How budget reservations work says what a hold does and how it ends.
How the execution goes on
The execution goes on at the node it stopped at.
Queue lets it pass through Default.
Require Approval leaves through Approved or Rejected.
AI Model tries the call again, or reads the answer of the provider.
Waiting executions are picked up once a minute, so an execution goes on within a minute after its time comes or its approval is decided. A call the provider runs in the background is asked about every few seconds — 30 at most by default.
How long an execution may wait
An execution may wait 72 hours in all by default, counted from its first pause; one sent in async mode — from the moment it was accepted. Past that it ends
failedwithparked_expired. A call the provider is still running when the time is up ends the same way.The delay of Queue and the time to decide of Require Approval may not be longer than 71 hours by default: a longer one is refused when the flow is published.
A pool waits for a connection three times at most by default. After that the call fails as it would without waiting.
An approval nobody decides in time counts as a refusal.
Where a pause may not stand
Queue and Require Approval may not be reachable from Reserve Budget before the AI Model it reserves for, because a waiting execution holds no reservation. Such a flow is not published, with the code park_inside_finance_chain. The money chain says which connections the check follows.
Watch the executions that wait
An execution that waits is Waiting on the Executions tab of its flow. Live on the canvas of the flow shows at which node each one stands and what it waits for — Inspect an execution. The approvals wait on Approvals: Approvals says how to decide them.
Where to go next
Queue — the node that makes an execution wait a set time.
Async runs and waiting — wait for the result in an application.
Approvals — decide on an execution that waits for a person.
Require Approval — the node that waits for a decision.
AI Model — when an execution waits at the model node.