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

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. A timeout is therefore a transport-level AbortError, not a DeviceParkHttpError and not 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.

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.