Documentation / Advanced
Set deadlines and retry bounds
Execution timeouts, retry attempts, rework loops and coordination TTL are different controls.
Bound a handler attempt
Engine timeout precedence: phase timeout, then sla.timeout_secs, workflow defaults.phaseTimeout, then 300 seconds. Local handler execution uses its SLA/manifest timeout; it is not a cloud-watchdog certification.
{
"sla": {
"timeout_secs": 1,
"max_attempts": 2
}
}Complete example · JSON / YAML
JSON
{
"name": "advanced-timeouts",
"version": "1.0.0",
"lanes": {
"inline": {
"mode": "sync_lambda",
"target": "lambda://local-inline"
}
},
"phases": {
"work": {
"service": "hello",
"lane": "inline",
"scope": "root",
"terminal": true,
"sla": {
"timeout_secs": 1,
"max_attempts": 2
}
}
},
"defaults": {
"phaseTimeout": "5m"
},
"coordination": {
"defaultTtl": "15m"
}
}YAML
name: advanced-timeouts
version: 1.0.0
lanes:
inline:
mode: sync_lambda
target: lambda://local-inline
phases:
work:
service: hello
lane: inline
scope: root
terminal: true
sla:
timeout_secs: 1
max_attempts: 2
defaults:
phaseTimeout: 5m
coordination:
defaultTtl: 15mrippflow controls validate advanced-timeouts.workflow.yaml --jsonExpected: ok: true. This checks the contract; deployment/enforcement is separate.
Try an intentional timeout
Download the manifest and slow handler. This local command intentionally exits nonzero after the handler deadline. The CLI does not emulate cloud retry scheduling.
rippflow dev advanced-timeouts.workflow.json --handlers advanced-timeout.handlers.jsonKeep retry and retention separate
max_attempts bounds worker attempts; max_loops bounds QA rework. The failure recipe exercises retries and DLQ simulation. The watchdog handles stalled work in an installation.
Coordination defaults to at least 900 seconds. For phases longer than 300 seconds, core extends retention to at least the phase timeout plus 900 seconds. TTL is not the phase deadline.