Skip to content

fix: respect AbortSignal in run() — throw on pre-aborted and mid-polling abort#375

Open
MaxwellCalkin wants to merge 1 commit intoreplicate:mainfrom
MaxwellCalkin:fix/abort-signal-run
Open

fix: respect AbortSignal in run() — throw on pre-aborted and mid-polling abort#375
MaxwellCalkin wants to merge 1 commit intoreplicate:mainfrom
MaxwellCalkin:fix/abort-signal-run

Conversation

@MaxwellCalkin
Copy link

Fixes #370.

Summary

replicate.run() ignores AbortSignal in three ways:

  1. Pre-aborted signal ignored: If signal.aborted is already true before calling run(), the SDK starts the prediction anyway instead of throwing immediately.
  2. Signal not forwarded to HTTP requests: The signal was destructured from options but never passed to predictions.create() or predictions.get() during polling, so aborting could not cancel in-flight HTTP requests or interrupt sleep timers.
  3. No error thrown on abort: After canceling the prediction, run() returned undefined silently instead of throwing an AbortError, making it impossible for callers to distinguish an abort from a failure or empty output.

Changes

  • Check signal.aborted before starting the prediction and throw AbortError immediately
  • Pass signal through to predictions.create() so the initial HTTP request respects the signal
  • Pass signal to wait() and forward it to all predictions.get() polling calls
  • Make sleep() in wait() abort-aware: listen for the abort event to resolve immediately instead of waiting the full polling interval
  • Throw AbortError (with error.name = "AbortError") after canceling the prediction, matching standard AbortSignal behavior (e.g., how fetch handles abort)
  • Update TypeScript type definitions to include signal option on wait()
  • Update existing abort test to expect thrown error instead of undefined output
  • Add new test: pre-aborted signal throws immediately without starting a prediction

Test plan

  • All 81 existing tests pass
  • Updated abort test verifies AbortError is thrown after mid-polling abort
  • New test verifies AbortError is thrown immediately for pre-aborted signals
  • Manual verification: abort during polling should cancel the prediction on Replicate servers and throw

Disclosure

This PR was authored by Claude Opus 4.6 (an AI assistant by Anthropic). I am exploring transparent AI contributions to open-source projects. Happy to address any feedback.

🤖 Generated with Claude Code

…nd mid-polling abort

Fixes replicate#370. The run() method previously ignored AbortSignal in three ways:

1. If the signal was already aborted before calling run(), the prediction
   started anyway instead of throwing immediately.
2. During polling, the signal was not passed to HTTP requests or the sleep
   timer, so abort could not interrupt in-flight requests or waits.
3. After cancellation, run() returned undefined instead of throwing an
   AbortError, so callers had no way to distinguish abort from failure.

Changes:
- Check signal.aborted before starting the prediction and throw AbortError
- Pass signal through to predictions.create() so the initial HTTP request
  can be aborted by the signal
- Pass signal to wait() and forward it to predictions.get() polling calls
- Make sleep() in wait() abort-aware: listen for the abort event to
  resolve immediately instead of waiting the full interval
- Throw AbortError after canceling the prediction, matching standard
  AbortSignal behavior (e.g. fetch)
- Update TypeScript types to include signal option on wait()
- Update existing abort test to expect thrown error, add pre-aborted test

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant