SpineError, so a single
catch (err instanceof SpineError) clause catches anything the SDK can
throw.
Error hierarchy
Inspecting errors
SpineAPIError carries the HTTP status, the server’s error message, the
request id (useful when reporting issues), and the raw body:
Client-side short-circuit
Some validation runs locally without a network round-trip so you get the same typed error regardless of where the check fired:Automatic retries
The SDK retries transient failures automatically with jittered exponential backoff:| Failure | Retried? | Notes |
|---|---|---|
| Connection errors (DNS, refused, TLS) | Yes | Up to maxRetries. |
| HTTP 5xx | Yes | Up to maxRetries. |
| HTTP 400 / 401 / 404 | No | Thrown immediately. |
SpineServerError
or SpineConnectionError) is thrown.
Tuning retries
Timeouts
The HTTP timeout is 60 seconds per request by default. Override it withtimeoutMs:
waitForCompletion) is independent and defaults
to 15 minutes. Tune it per call:
SpineTimeoutError is thrown when either timeout fires.
SpineRunFailedError
Thrown by waitForCompletion when the run terminates with
status: 'failed'. Carries runId and an errors: { error: string }[]
list.
If you would rather handle the failed run as a value:
'partial' status is not a failure — the run produced usable
output with some blocks skipped. Inspect terminal.errors on the
returned object.