Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.goldsky.com/llms.txt

Use this file to discover all available pages before exploring further.

Tasks are the core execution units in Compose. A task is a durable workflow that can execute its own logic as well as trigger other tasks. Tasks run in a sandboxed environment and cannot access the file system, network, blockchains, etc, without communicating outside of the sandbox by calling Context Functions. This allows all task functionality to be fully auditable and verifiable. Each task is a TypeScript module that exports a main function with access to context functions for durable operations. The main function receives the injected context as its first argument and the payload sent by the trigger as its second argument. Types for context functions are stored in the local .compose/ folder and can be referenced from your task files like so: 
import { TaskContext } from "compose";

​
Task Structure

Every task must export a main function with this signature: 
import { TaskContext } from "compose";

export async function main(
  // injected by compose at runtime
  context: TaskContext,
  // the payload sent with the trigger (e.g. an HTTP request body or onchain log).
  // Empty when a task is triggered by cron.
  payload?: Record<string, unknown>,
): Promise<unknown> {
  // Task implementation
}
The runtime loads your task file and looks for an exported main function. If none is found, the task fails to load. Default exports, run, and lifecycle hooks like onStart / onShutdown are not supported — main is the single entrypoint.

​
Task Triggers

Tasks are invoked by “triggers” — see Task Triggers for details. The supported trigger types are:
  • Cron — called on a schedule expressed as a cron expression, with no payload.
  • HTTP — called by your application or CLI with various auth options. The request body is passed as the payload.
  • Onchain — triggered by onchain events, called with a raw log payload decodable via Contract classes.

​
Task-Level Retry Configuration

Configure retries in your app manifest: 
tasks:
  - name: "unreliable_task"
    path: "./tasks/flaky.ts"
    retry_config:
      max_attempts: 5
      initial_interval_ms: 2000
      backoff_factor: 1.5
How Task Retries Work:
  1. Task Failure: If the task throws an error, the durable execution engine marks the attempt as failed.
  2. Retry Delay: Waits initial_interval_ms before the first retry.
  3. Exponential Backoff: Each subsequent retry interval is the previous one multiplied by backoff_factor.
  4. Retry Sequence (for the example above): delays of 2000ms → 3000ms → 4500ms → 6750ms between the 5 attempts.
  5. Final Failure: After max_attempts attempts, the task is permanently failed.
  6. Default Behavior: When retry_config is omitted, tasks run with max_attempts: 1 — i.e. no retries.

​
Task Context

A task’s main() function is invoked with a context object — see Context for full details. Here’s a brief overview of what context enables:
  • State management — Collections
  • Blockchain interactions — evm
  • HTTP requests — fetch
  • Task-to-task execution — callTask
  • Reading env variables — env

​
Next Steps

Context

Get detailed API docs for all available context functions for HTTP, blockchain, and database operations.

Task Triggering

Learn how to trigger tasks and query your application via HTTP API.