transloadit/uppy · warning · DOMException

AbortError

AbortError

Error message

Request aborted

What it means

The generic `request` method checks the AbortSignal after waiting for connectivity (waitForOnline) and throws `new DOMException('Request aborted', 'AbortError')` if the caller cancelled while the client was offline-waiting. This gives a standard AbortError so callers' `signal.aborted` handling and `e.name === 'AbortError'` checks work uniformly.

Source

Thrown at packages/@uppy/aws-s3/src/s3-client/S3mini.ts:306

    data,
    onProgress,
    signal,
    contentType,
    shouldRetryCredentials = true,
  }: {
    request: IT.PresignableRequest
    data?: XMLHttpRequestBodyInit
    onProgress?: IT.OnProgressFn
    signal?: AbortSignal
    contentType?: string
    shouldRetryCredentials?: boolean
  }): Promise<{ xhr: XMLHttpRequest; url: string }> {
    // Wait for online before starting
    await this.waitForOnline(signal)

    // Check if aborted while waiting for online
    if (signal?.aborted) {
      throw new DOMException('Request aborted', 'AbortError')
    }

    try {
      const { url } = await this.signRequest(request)

      const xhr = await this.xhr({
        url,
        method: request.method,
        data,
        onProgress,
        signal,
        contentType,
      })

      return { xhr, url }
    } catch (err: unknown) {
      // NetworkError or errors with attached XHR (from onAfterResponse throws)
      if (

View on GitHub (pinned to 5d4dedd02a)

Solutions

1. Treat AbortError as an intentional cancellation, not a failure: check `err.name === 'AbortError'` and skip retries.
2. Ensure only one cancellation source owns the controller; if you compose timeout + user-cancel signals, use AbortSignal.any([...]).
3. If you didn't intend cancellation, find which code calls `controller.abort()` (timeout, unmount cleanup, route change).

Example fix

// before
try { await s3.putObject(...) } catch (e) { retry() } // retries user-cancelled request
// after
try { await s3.putObject(...) } catch (e) {
  if (e.name === 'AbortError') return // intentional cancel, don't retry
  throw e
}

const isAbortError = (e: unknown): e is DOMException =>
  e instanceof DOMException && e.name === 'AbortError'

try { await s3.uploadPart(...) } catch (e) { if (e instanceof DOMException && e.name === 'AbortError') return /* cancelled — do not retry */; throw e }

When it happens

Trigger: The client goes offline, request() parks in waitForOnline, and the app aborts via AbortController (e.g. user cancelled an upload) — or the signal was already aborted when the check runs. All S3 operations (putObject, uploadPart, createMultipartUpload, etc.) funnel through request(), so any of them can surface this.

Common situations: User cancels an upload in the UI during a network dropout; a timeout wrapper aborts requests that stall waiting for connectivity; navigating away from a page that aborts in-flight uploads; deliberate offline-pause then cancel flows.

Related errors

• NETWORK
• Either signRequest or getCredentials must be provided
• signRequest must be a function
• [s3mini] endpoint must be a non-empty string
• getCredentials must be a function

AI-assisted analysis of transloadit/uppy@5d4dedd02a (2026-08-28). Data as JSON: /api/errors/be2b264d3f77af8e. Report an issue: GitHub.