transloadit/uppy · error · Error

File data is missing for file ${options.file.id}

Error message

File data is missing for file ${options.file.id}

What it means

This is Companion's top-level Express error handler in packages/@uppy/companion/src/standalone/index.ts. When NODE_ENV is production, it masks the underlying error details and returns a generic 500 with only a requestId, to avoid leaking internal error messages or stack traces to clients. The real cause is logged server-side via logger.error(err, 'root.error', req.id).

Source

Thrown at packages/@uppy/aws-s3/src/S3Uploader.ts:86

  etag?: string
}

export default class S3Uploader<M extends Meta, B extends Body> {
  readonly #data: NonNullable<LocalUppyFile<M, B>['data']>
  #key: string | undefined
  readonly #options: S3UploaderOptions<M, B>
  readonly #eventManager: EventManager<M, B>

  #chunks: Chunk[] = []
  #chunkState: ChunkState[] = []
  #shouldUseMultipart: boolean = false
  #uploadId?: string
  #uploadHasStarted: boolean = false
  #abortController: AbortController | undefined

  constructor(options: S3UploaderOptions<M, B>) {
    if (options.file.data == null) {
      throw new Error(`File data is missing for file ${options.file.id}`)
    }
    this.#options = options
    this.#data = options.file.data
    this.#eventManager = new EventManager(options.uppy)

    // Detect resume state from file (persisted by Golden Retriever across page refreshes).
    // Must run before #initChunks so it can force multipart mode for resumed uploads.
    const resumeState = options.file.s3Multipart
    if (resumeState) {
      this.#key = resumeState.key
      this.#uploadId = resumeState.uploadId
      this.#uploadHasStarted = true
    }

    const fileSize = options.file.data.size

    // Determine if we should use multipart
    // If we're resuming a multipart upload, force multipart. Otherwise use

View on GitHub (pinned to 5d4dedd02a)

Solutions

1. Check the Companion server logs for the 'root.error' entry (keyed by the returned requestId) to see the actual stack trace
2. Reproduce locally with NODE_ENV=development to get error.message and err in the response body
3. Verify provider credentials (key/secret) and that the provider's API is reachable from the Companion host
4. If the error comes from a custom provider, wrap its network calls and validate responses before use

Example fix

// before (unclear root cause)
res.status(500).json({ message: 'Something went wrong', requestId: req.id })

// after: inspect via logs
logger.error(err, 'root.error', req.id) // then grep server logs for requestId returned to the client

// wrap Companion HTTP calls client-side
try {
  await fetch(companionUrl + path, opts)
} catch (err) {
  // surface requestId to the user; correlate with server logs
  reportToOps(responseBody.requestId)
  throw new RetryableError('companion unavailable')
}

When it happens

Trigger: Any unhandled exception thrown in a route handler, middleware, or provider call that propagates to the Express error handler while NODE_ENV=production (e.g. an upstream provider API failure, a malformed request that crashes parsing, or a bug in a custom provider).

Common situations: Developers see only 'Something went wrong' and cannot reproduce locally where NODE_ENV is development (which returns error.message). Common causes: Companion misconfiguration, an expired/invalid provider token causing an exception mid-request, or network failures to the provider's API.

Related errors

• Missing S3 object key for completing multipart upload
• [s3mini] fileType must be a string
• [s3mini] uploadId must be a non-empty string
• uploadUrls is required
• Failed to download file

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