retry

The retry block wraps a step and re-executes it on failure, with configurable attempts and backoff strategy.

Syntax

retry classify_with_retry
  ask classify using "anthropic:claude-sonnet-4-6"
    with task
      "Classify this text."
    returns
      category as text

Configuration

Retry behavior is configured via step attributes:

retry fetch_data, max: 3, backoff: "exponential"
  launch get_data
    from: "@mashin/actions/http/get"
    with task
      url: input.api_url

Attribute	Type	Default	Description
max	number	3	Maximum number of attempts
backoff	text	”exponential”	Backoff strategy: “none”, “linear”, “exponential”
delay	number	1000	Base delay in milliseconds

How it works

1. The wrapped step executes normally
2. If it fails, the retry logic checks the attempt count
3. If attempts remain, it waits according to the backoff strategy and retries
4. If all attempts fail, the retry block fails with the last error
5. Each retry attempt is a separate governance event (individually governed)

Backoff strategies

• none: Retry immediately
• linear: Wait delay * attempt_number milliseconds
• exponential: Wait delay * 2^(attempt_number - 1) milliseconds

Governance

Each retry attempt is individually governed. The governance pipeline sees each attempt as a separate directive. Cost accumulates across all attempts.

Ledger events

The execution trace records each attempt with its outcome. The final result (success or failure) is the block’s result.

Step type

retry blocks have step type :control in the execution trace. The wrapped step retains its own type.

See also

• on failure — handle failures with custom logic
• together — parallel execution
• decide — conditional branching