Each item in @stitchapi/download already rides core's per-attempt retry (retry config), and a rejected ItemResult carries a classification — retryable: boolean + a machine code (UND_ERR_SOCKET, HTTP_404, IDLE_TIMEOUT, …). But once an item settles as a terminal failure, the batch does not re-attempt it; the caller must re-add it manually.
Proposal
An opt-in batch-level retry that re-enqueues items whose classification is retryable (transport faults, 5xx/429/408, IDLE_TIMEOUT) up to N times with backoff, preserving FIFO admission + per-item-settle semantics:
downloadAll(urls, { itemRetries: 3, itemBackoff: { base: 1000 } });
A retried item re-joins the queue (FIFO), its progress resets, and a non-retryable failure (terminal 4xx, cancellation) is never retried. The retryable field exists precisely to drive this.
Introduced alongside #451.
Each item in
@stitchapi/downloadalready rides core's per-attempt retry (retryconfig), and a rejectedItemResultcarries a classification —retryable: boolean+ a machinecode(UND_ERR_SOCKET,HTTP_404,IDLE_TIMEOUT, …). But once an item settles as a terminal failure, the batch does not re-attempt it; the caller must re-addit manually.Proposal
An opt-in batch-level retry that re-enqueues items whose classification is
retryable(transport faults,5xx/429/408,IDLE_TIMEOUT) up to N times with backoff, preserving FIFO admission + per-item-settle semantics:A retried item re-joins the queue (FIFO), its progress resets, and a non-retryable failure (terminal
4xx, cancellation) is never retried. Theretryablefield exists precisely to drive this.Introduced alongside #451.