Skip to main content
Context functions allow task sandboxes to access the outside world. Context functions support individual retry configuration and are automatically logged for auditing and debugging. All communication outside of the task sandbox happens via Context Functions, making Compose apps run deterministic, given the same world context.

Retry Configuration

All Context functions accept an optional retry configuration:
How Context Function Retries Work:
  • Each context function call can have its own retry configuration
  • If a context function fails, it retries according to its configuration
  • If all context function retries are exhausted, the context function will throw
  • If you don’t catch a failed context function call, a task-level retry may trigger, restarting the task and any context-function retries

Durable execution and context caching

Compose provides durable execution guarantees. All context function calls are deterministically cached — if a task is interrupted (e.g. by a restart or deployment) and resumed, context functions that already completed will return their cached results instead of re-executing. This means:
  • Transactions that already succeeded will not be re-sent
  • Fetch calls that already returned will not be re-made
  • Collection operations that already completed will not be repeated
This caching is scoped to each individual task run. Cached results are automatically cleaned up when the run completes (success or failure). Non-deterministic values, such as timestamps or random IDs, must be produced through ctx.sideEffect() so a replay returns the same value instead of recomputing it.
By default, read-only context calls make up to 3 attempts (max_attempts: 3, initial_interval_ms: 500, backoff_factor: 2). This covers readContract, simulate, getBalance, and ctx.fetch with GET, HEAD, or OPTIONS. Mutations such as callTask, writeContract, sendTransaction, and ctx.fetch with POST, PUT, PATCH, or DELETE default to a single attempt (max_attempts: 1). Pass a retryConfig to override either default.

Overview of key context properties and functions

Here’s a brief overview of what context enables. Use the left nav or links below to find full reference docs.

Full TaskContext interface

See the turbo reference for the full type definitions used above (TurboPipeline, TurboPipelineStatus, ValidateResult, etc.).

Logger

context.logger is a run-aware structured logger. Unlike console.log, logs emitted through context.logger are tagged with the current task name and run ID, which enables two powerful debugging workflows in the Compose dashboard:
  1. Search app-level logs, then jump to the run — On the Logs tab of your app, you can search for a log pattern across all runs. Each matching log entry includes a “View run” link that takes you directly to the full task run, where you can see the complete OpenTelemetry trace of everything that happened in that run.
  2. View run-specific logs — On any task run’s detail page, the Logs tab shows only logs from that specific run, making it easy to understand what happened in a single execution.

Usage

API

Each method takes a message string and an optional data object for structured metadata. BigInt values (common in EVM code) are automatically serialized as strings.

console.log vs context.logger

Both console.log and context.logger output to your terminal during local development. The difference is in the cloud: Use console.log for quick debugging. Use context.logger when you want logs that you can trace back to a specific task run in production.

Next Steps

Fetch

Make auditable HTTP requests with fetch.

Collections

Manage state across tasks and task runs with collections.