Skip to main content
All SDK errors embed *SandboxError, which implements the error interface. Use errors.As to match specific error types, or check the base *SandboxError to catch any Declaw error.

Error hierarchy


SandboxError

Base error type for all Declaw errors.
Branch on Code, not Message. Messages are prose and change between releases; codes are contract. It matters most where one status means several unrelated things — a 409 from sandbox creation is either CodeIdempotencyInProgress (the original create is still running) or CodeTemplateNotReady (the template needs a rebuild), and only the first is worth retrying.

NotFoundError

Returned when a sandbox or resource does not exist (HTTP 404).

AuthenticationError

Returned when the API key is missing or invalid (HTTP 401/403).

InsufficientBalanceError

Returned when the account has insufficient balance (HTTP 402).

RateLimitError

Returned when the API rate limit is exceeded (HTTP 429). Inspect RetryAfter and back off before retrying.

CommandExitError

Returned when a command exits with a non-zero exit code. Contains the full stdout, stderr, and exit code. Note that Run() returns both the *CommandResult and the error, so you can inspect output even on failure.

TimeoutError

Returned when an operation exceeds its configured timeout (HTTP 408).

InvalidArgumentError

Returned when invalid arguments are passed to an API call (HTTP 422).

NotEnoughSpaceError

Returned when the sandbox filesystem is full (HTTP 507).

TemplateError / BuildError

Returned on template build or retrieval errors.

Idempotent sandbox creation

Sandbox.Create sends an Idempotency-Key automatically. A create that times out or is retried will not leave a second running, billable sandbox behind: the key is generated once per logical create and reused across that call’s retries, so the server replays the original response instead of starting a new sandbox. The SDK also retries a 409 carrying CodeIdempotencyInProgress on your behalf, honoring Retry-After. That is how the sandbox ID is recovered when the original response was lost — you do not need to write that loop.
The SDK retries within its own budget (a few attempts with backoff). If the original create outlives that — a slow cold start under load, say — the error still surfaces, carrying CodeIdempotencyInProgress. Retrying the same call is safe and is the right response: it is a fresh logical create, so it gets a fresh key, and the server will not have duplicated anything in the meantime.
Two codes are worth handling yourself:

Catching all Declaw errors


Retry patterns

Simple retry with backoff

Handle rate limits

Handle non-zero exit codes