Release candidate — 1.0.0-rc.7
StitchAPI
GuidesResilience

Timeouts

Enforce total and per-attempt timeouts with a real AbortSignal.

Add timeout when a slow or hung response shouldn't be allowed to block the caller indefinitely — the stitch bounds the call with a real AbortSignal, so a breached deadline actually aborts the in-flight request rather than leaking it.

Example

import {  } from 'stitchapi';

const  = ({
    : 'https://api.example.com',
    : '/report',
    : { : '10s', : '3s' },
});

Each call to report() gives every attempt at most 3 seconds and the whole call at most 10 seconds; whichever fires first aborts the request.

Options

The two fields name the two scopes: total bounds the entire call across every retry, each bounds a single attempt on its own. Both accept either a number of milliseconds (3000) or a duration string ('3s'), so total: '10s' and total: 10000 are equivalent.

The deadline is backed by a real AbortSignal: when it elapses the stitch aborts the underlying request — the connection is actually cancelled, not just ignored — and the call fails with a timeout.

With retry, the two timeouts compose: each gates one try, while total caps the sum of all tries plus their backoff waits, so a long enough total is what lets a slow attempt be retried at all. Neither scope spans separate calls, so a submit-then-poll job needs its deadline built a level up — submit, poll, download works through the three-call version and what each choice costs.

Anti-pattern: with retry enabled, don't rely on each alone to bound how long the caller waits — it bounds one try, not the call, so several retries plus their backoff waits can block the caller far past your intended deadline. Set total to cap the whole call instead. See Retry.

A breached deadline aborts the call and surfaces as a timeout error. See STITCH_TIMEOUT for how it reads and how to fix it.

See Reference → Config types for the full TimeoutOptions shape.

See also

On this page