Error Handling

Handle configuration, HTTP responses, transport failures and cleanup failures separately. SDK version 1.0.1 does not define an allocation-wait timeout or a fixed catalog of backend error codes.

Failure Types

Node.js

The package exports these SDK errors:

Error	When it is used	Useful fields
DeviceParkConfigError	Missing client configuration or invalid SDK method argument	message
DeviceParkHttpError	Device Park returned a non-2xx response	status, body
DeviceParkSerializationError	JSON serialization or parsing failed	message, cause
DeviceParkError	Base class for SDK-defined errors	message, cause

Java

Failure	Exception
Invalid builder or method argument	IllegalArgumentException
HTTP, authentication, network or request timeout failure	RuntimeException with the original IOException as its cause
Client close failure	IOException

.NET

Error	When it is used	Useful members
DeviceParkConfigException	Missing client configuration or invalid SDK method argument	Message
DeviceParkHttpException	Device Park returned a non-2xx response	Status, ErrorCode, ErrorMessage, Body
DeviceParkSerializationException	JSON serialization or parsing failed	Message, InnerException
DeviceParkException	Base class for SDK-defined errors	Message

All .NET exception types live in Testinium.DevicePark.Errors.

Backend Error Envelope

Device Park returns a consistent error body for failed requests:

{
  "errorCode": "ALLOCATION_ERR003",
  "errorMessage": "No matching devices found for allocation",
  "errorDetails": null
}

The .NET SDK parses this envelope into DeviceParkHttpException.ErrorCode and ErrorMessage; both are null when the response does not use the envelope. Body always carries the raw response.

The Node.js SDK exposes the raw body through DeviceParkHttpError.body.

errorDetails is populated only for validation failures (ERR001), where it names the rejected field. Do not couple automation logic to specific codes without agreeing on them with the Device Park team first.

Handle Errors

import {
  DeviceParkConfigError,
  DeviceParkHttpError,
  DeviceParkSerializationError
} from "@device-park/public-sdk";

try {
  const devices = await client.devices().list();
  console.log(devices.data);
} catch (error) {
  if (error instanceof DeviceParkConfigError) {
    console.error("Invalid SDK configuration:", error.message);
  } else if (error instanceof DeviceParkHttpError) {
    console.error("Device Park request failed:", error.status, error.body);
  } else if (error instanceof DeviceParkSerializationError) {
    console.error("Unexpected response format:", error.message);
  } else if (error instanceof Error && error.name === "AbortError") {
    console.error("Device Park request timed out");
  } else {
    throw error;
  }
}

Node.js request timeout uses AbortController, so a timeout surfaces as a transport-level AbortError. In .NET it surfaces as TaskCanceledException from HttpClient.Timeout. Neither is a DeviceParkHttpError / DeviceParkHttpException, and neither is an allocation-specific error code.

Java SDK version 1.0.1 does not expose a structured HTTP status field. If machine-readable status handling is required, agree on that behavior before coupling automation logic to exception message text.

Allocation Waiting

Creating an allocation and waiting for a device are separate concerns. The SDK returns the allocation response; it does not keep polling until a device is assigned.

Your runner should:

Store allocationId immediately.

Inspect the same allocation until deviceSerial is assigned.

Apply an application-level deadline suitable for the CI job.

Release the allocation if the deadline is exceeded.

Do not assume a special queue-timeout exception or status code. None is defined by the public SDK contract.

Set the queue deadline in your test runner. The SDK does not poll automatically and does not throw a dedicated allocation-timeout error.

Cleanup

Cleanup order is session, allocation, client:

Stop every active sessionId.

Release the allocationId after the final session.

Close the client. Java uses try-with-resources, Node.js await client.close(), and .NET a using declaration.

Catch cleanup failures separately so they do not replace the original test failure. Include resource identifiers in logs, but never include credentials, access tokens or authorization headers.