Skip to main content

Execute a function

Queue a run instead of waiting for it, collect the result by task id, and control what the function receives.

Prerequisites​

  • An app slug and a function slug.
  • Credentials for the site, unless the function is public.
  • The function must be active. An inactive function returns 404.

Execute and wait​

A call that waits is the default shape and is covered end to end in Create, run, and delete a function. The response carries the return value in data and the invocation record alongside it, and the request waits up to the execution timeout, 900 seconds by default.

Everything below is for the other shape: work that is slow, or that nobody is waiting on.

Execute without waiting​

import {Functions} from '@taruvi/sdk';

const queued = await new Functions(client).execute('FUNCTION_SLUG', {
params: {invoice_id: 'INV-1042'},
async: true,
});

The response is 202 with data set to null. Keep the celery_task_id from the invocation record; it is how you collect the result.

The Python SDK names this parameter is_async, while the REST body and the JavaScript SDK use async.

Read the result later​

task_result = client.functions.get_result(task_id)
statusMeaning
PENDINGNot finished
SUCCESSFinished, with the return value
FAILUREFinished, with a traceback

Nothing notifies you when a function completes, so poll at a rate that matches the work rather than tightly.

Reading results is not available in the JavaScript SDK, which exposes only execute.

Pass parameters​

Parameters travel in params. Query-string values are merged in too, with the body winning on a key collision.

Your code receives params with three keys added by the platform: __function__, request, and __method__. The execute endpoint accepts POST, GET, PATCH, and PUT, and __method__ tells the function which verb was used, so one function can serve several.

If you omit async, the function's own default applies.

Verify​

An asynchronous call returns 202 and a task id that later resolves to SUCCESS or FAILURE.

Every execution creates an invocation record, so a run that produced no record did not start. For event-triggered functions, the usual cause is filter conditions that did not match.