Spojit retries node executions on transient failures (network timeouts, rate limits, brief server errors) so workflows survive routine flakiness without manual re-runs. Retry behaviour is configurable per node, with sensible defaults and hard caps.Documentation Index
Fetch the complete documentation index at: https://docs.spojit.com/llms.txt
Use this file to discover all available pages before exploring further.
What gets retried
When a node fails, Spojit looks at the failure and decides whether retrying makes sense:| Class | Examples | Retried? |
|---|---|---|
| Transient | Timeouts, connection errors, HTTP 408/425/429/500/502/503/504, error messages containing “rate limit” / “timeout” / “service unavailable” | Yes — automatically |
| Permanent | Bad input, schema mismatches, unauthorized (401), forbidden (403), not found (404), validation errors (422) | No — retry won’t help |
| Tool-reported | The connector returned an error, but Spojit can’t tell whether retrying is safe | Only if Retry on tool errors is on |
Configuring retries on a node
Open the node in the canvas and find the Retry section in the properties panel. Available on Connector and Knowledge nodes.- Max attempts (1–5).
1is the default — no retry. Setting it higher enables transient retry. - Retry on tool errors (off by default). When on, Spojit also retries failures where the connector reported an error without a clear cause. This may create duplicate side effects for non-idempotent operations (e.g.
create_order,send_email). Enable only on tools you’re sure are safe to retry.
1, the rest of the section collapses — there’s nothing else to configure.
Backoff between attempts
Failed attempts wait before the next try, increasing each time: 1 s → 2 s → 4 s → 8 s → 16 s, capped at 30 s. With 5 attempts you’ll wait up to roughly 31 s of backoff in addition to actual node execution time.Retry scope by node mode
What “max attempts” counts depends on the node mode:Agent mode (Connector node)
In agent mode, the AI may call several tools in sequence to complete the step. Spojit retries each individual tool call, not the whole step. If the agent has already used tools A and B successfully and tool C fails transiently, only C is retried — A and B are not re-run.Max attempts: 3 here means each tool call the agent makes can retry up to 3 times. A single agent step that calls many tools could do many invocations in total.
Direct mode (Connector node), Knowledge node in query mode
The node runs a single operation.Max attempts: 3 means the whole step runs at most 3 times. Each attempt is a fresh execution.
Knowledge node in embed mode
Document embedding uses automatic retry on transient transport failures only. The Retry on tool errors toggle is intentionally hidden — retrying a partially-completed embed could create duplicate document chunks. Transient failures still retry as you’d expect.What “Retry on tool errors” actually does
Most retryable failures (timeouts,429, 5xx) are detected automatically — the toggle isn’t required for those.
The toggle covers a narrower case: when a connector returns an error message that doesn’t match a known transient pattern. Without the toggle, Spojit treats it as permanent and fails immediately. With the toggle, Spojit retries it.
Examples that always retry without the toggle:
- A connector returning
HTTP 429 Too Many Requests - A connector returning
Service Unavailable - Network timeouts
- A connector returning
Permission denied(could be a misconfiguration or could be a transient token state — the toggle is your call) - A custom tool returning a free-text error string Spojit doesn’t recognise