replicate.run() ignores AbortSignal - doesn't throw when signal is already aborted or becomes aborted during polling

[XStarlink]

replicate.run() ignores AbortSignal - doesn't throw when signal is already aborted or becomes aborted during polling

SDK Version

replicate: ^1.4.0

Environment

• Node.js 22
• Nuxt 4 / Nitro server

Description

When passing an AbortSignal to replicate.run(), the SDK does not properly respect the signal:

1. If the signal is already aborted before calling run(), the SDK should throw immediately but instead starts the prediction anyway.

2. If the signal becomes aborted during polling, the SDK continues polling until the prediction completes on Replicate's servers, then returns the result instead of throwing.

Expected Behavior

According to the documentation:

options.signal - An AbortSignal to cancel the prediction

The SDK should:

• Check signal.aborted before starting and throw AbortError if true
• Check signal.aborted during each polling iteration and throw if true
• Or listen to signal.addEventListener('abort', ...) to stop polling immediately

Actual Behavior

const controller = new AbortController()

const outputPromise = replicate.run(model, {
  input: { prompt: "..." },
  signal: controller.signal
})

// User cancels while run() is polling
setTimeout(() => controller.abort(), 4000)

await outputPromise // Continues until Replicate finishes, doesn't throw

Timeline from our logs

12:32:34 - replicate.run() called
12:32:38 - controller.abort() called (signal.aborted = true)
12:32:46 - run() finally returns (8 seconds later, after Replicate finished generating)start and during each poll iteration, similar to how `fetch` handles `AbortSignal`.

The prediction runs to completion on Replicate's servers even though the user cancelled, wasting compute resources.

Suggested Fix

The SDK should check signal.aborted at the start and during each poll iteration, similar to how fetch handles AbortSignal.