Skip to main content

Applications

Applications are the top-level decorators that define entry points for your applications. You can define as many applications as you want in your project. Each one of them will be assigned a unique HTTP entry point based on the name of the Python function.

Configuring Applications

The @application decorator allows you to specify the following attributes:
  1. tags - dict of tags to categorize the application.
  2. retries - Retry policy for every function in the application unless a function specifies its own retry policy. No retries by default if function failed. See Retries.
  3. region - The region where every function in the application will be deployed unless a function specifies its own region. Either us-east-1 or eu-west-1. The default is any of the regions.
The following code snippet shows an example of all the function attributes set to custom values.

Application inputs and output

Application functions take zero or more arguments which are the current request inputs. The inputs get deserialized from their JSON representation into Python objects specified in the arguments’ type hints. A reverse process happens for the request output. The object returned from the application function gets JSON serialized according to the return type hint of the function. The resulting JSON is returned as the HTTP response body of the application request. For example if your application function takes a single str argument and returns a str, then the request input and output should be JSON strings:
request input
request output
If you want to use multiple application request inputs with complex data structures, you can add more arguments and use type hints with your Pydantic model classes. Each type hint needs to be supported in Pydantic JSON mode. All basic type hints like str, int, float, bool, list, dict, set, tuple, None, Any, |, Pydantic model classes and more are supported. If a type hint is a union of multiple Python types, like str | int, then the request JSON input can match any of the types in the union.
request input
response output
The limit argument is optional so we can omit it from the request input. If an argument type hint is Any, then the corresponding request input can be any valid JSON value (string, number, object, array, boolean, null). The JSON value gets deserialized into the corresponding Python object (str, int/float, dict, list, bool, None). The same applies to Any return type hint (i.e. a Python dict gets serialized as JSON object, a Python list as JSON array, etc.). If type hints are not provided then they are treated as Any.

Calling Applications

You can call applications remotely using any HTTP client or Tensorlake Python SDK. Use empty POST request body if the application takes no arguments. A JSON serialized request body is passed if the application takes one argument. Use multipart/form-data request body if the application takes multiple arguments or one or more files (see uploading and downloading files). i.e. to call the hello_world application defined above (takes no arguments):
i.e. to call the greet application defined above (takes a single string argument):
i.e. to call the process_data application defined above (with multiple arguments):
If you pass an argument and application function doesn’t have it then it’s simply ignored. If an argument has a default value then you can omit it from the request input. Both of these features make it easy to update application code without breaking existing clients.

Uploading and downloading files

Application functions can receive files as current request inputs and return a file as a current request output. This makes it easy to build applications which process input files or produce an output file. File sizes of up to 5 TB are supported. The file input type is represented by the File class in Tensorlake SDK with the following interface:
When an argument has a File type hint, Tensorlake SDK doesn’t attempt to deserialize the input from JSON and instead passes a File object with original request input binary content and content type. When the return type hint is File, Tensorlake SDK doesn’t JSON serialize the returned File object. It instead sets the request output content type to the File.content_type and the HTTP response body to the raw bytes in File.content.
File.content field holds the raw bytes of the file uploaded to the application endpoint. At the moment, the SDK doesn’t support lazy loading large files, so the entire file is loaded into memory when the function is called. To pass a local file at /foo/bar/file_name.txt path to an application, you need to use a multipart/form-data HTTP request or just use Python SDK.

Functions

Functions are the building blocks of applications. They are Python functions decorated with the @function decorator. Tensorlake functions can call other Tensorlake functions. The function call blocks until the called function returns its output to the calling function. For example, a simple application function which calls another function to process its input:
Every Tensorlake function call:
  • is executed in its own function container,
  • supports durable execution,
  • can run in parallel with other function calls,
  • can be retried independently if it fails,
  • has its own resource limits (CPU, memory, disk, GPU, timeout),
  • has its logs available in Tensorlake logging tools,
  • has its execution timeline available in Tensorlake tracing tools,
  • can report progress updates to extend its timeout,
  • can share state with other function calls of the same application request.
Every Python function decorated with @function becomes a Tensorlake function and thus gets all these capabilities automatically.

Configuring Tensorlake functions

The @function decorator allows you to set the following attributes:
  1. description - A description of the function’s purpose and behavior.
  2. cpu - The number of CPUs available to the function. The default is 1.0 CPU. See CPU.
  3. memory - The memory GB available to the function. The default is 1.0 GB. See Memory.
  4. ephemeral_disk - The ephemeral /tmp disk space available to the function in GB. The default is 2.0 GB. See Ephemeral Disk.
  5. gpu - The GPU model available to the function. The default is None (no GPU). Please contact support@tensorlake.ai to enable GPU support.
  6. timeout - The timeout for the function in seconds. The default is 5 minutes. See Timeouts.
  7. image - The image to use for the function container. A basic Debian based image by default. See Images.
  8. secrets - The secrets available to the function in its environment variables. No secrets by default. See Secrets.
  9. retries - Retry policy for the function. No retries by default if function failed. See Retries.
  10. region - The region where the function will be deployed. Either us-east-1 or eu-west-1. The default is any of the regions.
The following code snippet shows an example of all the function attributes set to custom values.

Function inputs and output

Tensorlake functions are not exposed as HTTP entry points unlike application functions. Because of this Tensorlake functions have minimal limitations on their signatures. Arguments and return value don’t require any type hints but have to be picklable. Most Python objects are picklable, except special cases like Processes, Threads, database connections, etc. If a Tensorlake function argument or return value is a Tensorlake SDK File object, then it bypasses pickling and is passed as-is to and from Tensorlake functions.

Application functions and Tensorlake Functions

Every application function decorated with @application() decorator is also a Tensorlake function. This is why every application function needs to be decorated with @function() decorator in addition to @application(). As application functions are HTTP entry points into Tensorlake applications, they have some differences compared to regular Tensorlake functions. Application functions:
  • Require JSON serializable type hints for all arguments and the return value.
  • Don’t support / and * in function arguments.
  • Don’t support *args and **kwargs.
  • Ignore function call arguments that are not defined in the function signature. This simplifies code migrations, i.e. if HTTP client sends extra arguments that the application function doesn’t take anymore after its code update.
Application functions can be called from regular Tensorlake functions. The call is executed in the current application request without creating a new one. So it behaves like a regular Tensorlake function call inside an application.

Classes

Sometimes a function needs one-time initialization, like loading a large model into memory. This is achieved by defining a class using the @cls decorator. Classes use their __init__(self) constructor to run any initialization code once on function container startup. The constructor can not have any arguments other than self. Any number of class methods can be decorated with @function.

Timeouts

When a function runs longer than its timeout, it is terminated and marked as failed. The timeout in seconds is set using the timeout attribute. The default timeout is 300 (5 minutes). Minimum is 1, maximum is 172800 (48 hours). Progress updates can be sent by the function to extend the timeout. See Request Context.

Retries

When a function fails by raising an exception or timing out, it gets retried according to its retry policy. The default retry policy is to not retry the function call. You can specify a custom retry policy using the retries attribute. If you allow retries, it’s typically a best practice to ensure that the function is idempotent unless this is not required for your use case.
You can set default retry policy for all the functions in the application decorator. See the Configuring Applications guide.

Request Context

Functions can use a request context to share state between function calls of the same request. The context has information about the current request and provides access to APIs for the current request. You can access the request context directly from the RequestContext class.

Request ID

Each request has a unique identifier accessible via ctx.request_id. This is useful for logging and debugging.

Request State

The state API allows you to set and get key-value pairs scoped per request. Each new request starts with an empty state. Values can be any picklable object.

Streaming Progress Updates

The progress API allows you to stream execution progress from your functions. This is useful for monitoring long-running tasks and providing real-time feedback to users.
Key features:
  • Automatic timeout reset - Each progress update resets the function timeout, allowing long-running agents to run indefinitely
  • Real-time streaming - Stream updates to frontends via Server-Sent Events (SSE)
  • HTTP API access - Query progress updates programmatically for custom dashboards and monitoring
See the Streaming Progress guide for detailed API reference, frontend integration examples, and best practices.

Request Metrics

The metrics API allows you to record custom metrics for monitoring and debugging.

CPU

The number of CPUs available to the function is set using the cpu attribute. Minimum is 1.0, maximum is 8.0. The default is 1.0. This is usually sufficient for functions that only call external APIs and do simple data processing. Adding more CPUs is recommended for functions that do complex data processing or work with large datasets. If functions use large multi-gigabyte inputs or produce large multi-gigabyte outputs, then at least 3 CPUs are recommended. This results in the fastest download and upload speeds for the data.

Memory

GB memory available to the function is set using the memory attribute. Minimum is 1.0, maximum is 32.0. The default is 1.0. This is usually sufficient for functions that only call external APIs and do simple data processing. Adding more memory is recommended for functions that do complex data processing or work with large datasets. It’s recommended to set memory to at least 2x the size of the largest inputs and outputs of the function. This is because when the inputs/outputs are deserialized/serialized both serialized and deserialized representations are kept in memory.

Ephemeral disk

Ephemeral disk space is a temporary storage space available to functions at /tmp path. It gets erased when its function container gets terminated. It’s optimal for storing temporary files that are not needed after the function execution is completed. Ephemeral disks are backed by fast SSD drives. Using other filesystem paths like /home/ubuntu for storing temporary files will result in slower performance. Temporary files created using Python modules like tempfile are stored in ephemeral disk space inside /tmp. GB of ephemeral disk space available to the function is set using ephemeral_disk attribute. Minimum is 2.0, maximum is 50.0. The default is 2.0 GB. This is usually sufficient for functions that only call external APIs and do simple data processing. If the function needs to temporarily store large files or datasets on disk, then the ephemeral_disk attribute should be increased accordingly.