How it works
The attempt.repairs field
Inside your RunFn, attempt.repairs is an array of Message objects:
repairs is empty. On subsequent attempts, it contains messages describing exactly what failed and why.
Retry configuration
By default, Boundary retries up to 3 attempts with no delay between them.| Strategy | Delay pattern |
|---|---|
"none" | No delay between retries (default) |
"linear" | baseMs * attemptNumber |
"exponential" | baseMs * 2^attemptNumber |
Failure categories
Every failed attempt is classified into one of 8 categories. Each category has a default repair strategy:| Category | Meaning | Default repair |
|---|---|---|
EMPTY_RESPONSE | Model returned nothing | Re-prompt with schema instructions |
REFUSAL | Model refused the task | Re-prompt emphasizing the task is valid |
NO_JSON | Response contained no JSON | Ask for JSON output specifically |
TRUNCATED | JSON was cut off | Ask for complete, shorter response |
PARSE_ERROR | Malformed JSON | Send the parse error details |
VALIDATION_ERROR | Valid JSON, failed schema | Send schema violations |
INVARIANT_ERROR | Passed schema, failed rules | Send rule violations (your domain logic) |
RUN_ERROR | Your RunFn threw an error | No retry by default |
Custom repair overrides
You can override or disable repair for specific categories:false stops retrying for that failure type. Providing a function lets you craft custom repair messages.
When repair fails
If all attempts are exhausted without a valid output:Next steps
Results
The ContractResult type
Guarantees
What Boundary promises