Retry Configuration
All Context functions accept an optional retry configuration:- 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
By default, context functions have no retries (1 attempt). Pass a
retryConfig to enable retries on individual context function calls.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.- State Management - Collections
- Blockchain Interactions - evm
- HTTP requests - fetch
- Task to task execution - callTask
- Reading env variables - env
- Reorg handling - Reorgs
- Run-aware logging - logger
Full TaskContext interface
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:
- 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.
- 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
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:
console.log | context.logger | |
|---|---|---|
| Appears in app-level logs | Yes | Yes |
| Tagged with run ID and task name | No | Yes |
| ”View run” link in dashboard | No | Yes |
| Appears in run-specific Logs tab | No | Yes |
Structured data field | No | Yes |
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.