Errors in the TypeScript SDK

Introduction

Every failure the SDK raises is the same type, so one catch covers the lot. That includes serverless invocations, which reach a different API through the same client. The client itself comes from the overview.

Catching a failure

Every failure throws a typed RunwareError with a stable code enum and the offending parameter when applicable:

import { isRunwareError } from '@runware/sdk'

try {
  await client.run(payload)
} catch (err) {
  if (!isRunwareError(err)) { throw err }

  switch (err.code) {
    case 'quota':
      // Insufficient credits; prompt the user to top up
      break
    case 'rateLimit':
      // Back off and retry
      break
    case 'safety':
      // Prompt or image triggered a safety filter
      break
    default:
      throw err
  }
}

The error codes

The code value is one of validation, auth, quota, rateLimit, safety, provider, timeout, notFound, serverError, connection, aborted, unknown. Raw provider-specific codes are mapped onto this stable set, so your error-handling code does not have to track upstream changes.

The same enum is used by the Python SDK, so cross-language services can react to the same code values.

Serverless failures

A serverless invocation is refused through the same enum: an unknown endpoint raises notFound, an app that failed to build raises validation, and a cluster with no free capacity raises serverError. Reach for retryable rather than code when deciding whether to send the call again, since it already accounts for the difference between the two.

Errors that came from an HTTP response also carry statusCode and the RFC 9457 problemType, plus requestId, which is the one to quote in a support thread. A refusal that names a wait carries retryAfter in seconds.

A task that runs and fails does not throw. It comes back with status: 'failed' and its error set, because the invocation itself succeeded. Only a failure to start raises.