How a call becomes a result
Every function runs in the background, including the calls that look immediate. That single fact explains most of what follows: why a result can reach you by two routes, why every run leaves a record, and why "waiting" is a property of your request rather than of the function.
The path a call takes
The invocation is recorded before the run is queued, so an execution appears in the history even if it never starts. That record carries the task id, which is the handle for everything you look up later.
Waiting or not waiting
The async field on an execute request chooses between two shapes. Omit it and
the function's own default applies.
| Waiting | Queued | |
|---|---|---|
| You send | async: false | async: true |
| You get back | The return value | A task id |
| Status | 200 | 202 |
| Errors | Raised to you directly | Recorded against the run |
| Good for | Short work a caller needs an answer to | Slow work, or nobody waiting |
A waiting call holds the connection until the function finishes, up to 900 seconds by default. Event-triggered runs are always queued.
Reading a result later
A queued run gives you a task id. Two endpoints turn it into an outcome: one returns the result alone, the other returns the invocation record together with its result.
| Status | Meaning |
|---|---|
PENDING | Not finished |
SUCCESS | Finished, with the return value |
FAILURE | Finished, with a traceback |
Nothing notifies you when a function completes, so poll at a rate that matches the work rather than tightly.
What the function runs as
Before your code runs, TaruviBase prepares access so the function can call back into the platform, using the identity of whoever invoked it. Where there is no caller — a scheduled run, or an anonymous call to a public function — it uses the identity of whoever created the function.
That is why a function reaches only what its caller could reach. It goes through the same API as any other client, and the same permissions apply.
Every run leaves a record
An invocation record captures:
- The task id.
- How the run was triggered.
- Which version of the code ran.
- The log output collected during the run.
It does not hold the return value; that lives with the task result and is fetched when you ask for it.
Records persist for the life of the function, so treat anything a run received, returned, or logged as readable later. See Read logs and invocations.
When a run does not happen
Three things stop a function before it starts, and each looks different:
- The function is inactive. You get a 404, the same as for a function that does not exist.
- Filter conditions did not match. Event triggers only. The run is skipped with no record at all, so nothing failed and nothing was written.
- The account is not active. The run is rejected without retrying.
When an event-triggered run you expected is missing entirely, check the filter condition first. See Troubleshoot Functions.