Errors

The RepoError class, its normalized code union, retry hints, and secret redaction.

Every failure in repo-sdk throws a single error type — RepoError — with a normalized code so you can branch on the failure without parsing provider-specific status codes or message strings.

RepoError

import { RepoError } from 'repo-sdk';

try {
  await client.repos.get({ repo: 'capawesome-team/repo-sdk' });
} catch (error) {
  if (error instanceof RepoError) {
    error.code; // normalized failure code (see below)
    error.provider; // 'github' | 'gitlab' | 'bitbucket' | 'azure-devops' | 'gitea'
    error.status; // HTTP status, when available
    error.retryable; // whether retrying may succeed
    error.retryAfter; // seconds, when the provider sent Retry-After
  }
}

The code union

RepoErrorCode is a closed union. Map provider status codes to these once and your handling works across all four providers:

switch (error.code) {
  case 'rate_limited':
    // back off using error.retryAfter
    break;
  case 'unauthorized':
    // refresh credentials
    break;
  case 'unsupported':
    // the provider lacks this capability — see Capabilities
    break;
}

Retryable & retryAfter

retryable is a normalized hint: rate_limited and network_error are retryable, as are 5xx provider errors. When the provider sent a Retry-After header, retryAfter carries the number of seconds to wait.

The client already performs one bounded retry on rate_limited when Retry-After is small; see retry configuration. For anything beyond that, use retryable and retryAfter to build your own back-off.

Secret redaction

RepoError redacts known secrets from its message before the error is constructed. Tokens, API keys, and other credentials the SDK knows about are replaced with [redacted], so an error that bubbles up into your logs or an error tracker won’t leak the credential that produced it.