How to: Handle Errors

Introduction

This guide covers error handling when interacting with the C2C API. Gracefully handling HTTP errors is an essential component of a robust integration with any third-party service.

Types of Errors

Errors in your integration can originate from various sources, which we can categorize into four main groups:

• I/O Errors: Originate from hardware operations on your device, such as failed read/write operations
• Application Errors: Arise from issues within your application code
• Network Errors: Occur within the networking stack and are communicated by your networking library
• API Errors: Generated by Frame.io’s backend services

Each error category requires specific handling considerations. This guide primarily focuses on API errors, though we’ll address general strategies for the other categories as well.

How API Errors are Returned

Frame.io’s API communicates errors through two primary mechanisms:

• Status Codes: HTTP error codes that indicate the nature of the problem
• Error Messages: Payload content that provides additional error details, especially when multiple error conditions share the same status code

Error Status Codes

HTTP status codes are standardized numerical responses that communicate the outcome of an HTTP request. For more information, see Mozilla’s HTTP status code documentation or HTTP Cats for a more visual approach.

Each Frame.io API endpoint specifies an expected success status code—typically 200 (OK), 201 (Created), or 204 (No Content). You can verify success either by checking for these specific codes or by confirming the code falls within the 200-299 range.

Status codes above 399 indicate errors. Most API errors return 4XX codes (400-499), signifying client-side issues. Errors outside this range typically originate from network infrastructure between your device and our service, with the notable exception of 500 (Internal Server Error), which indicates an unexpected issue within our server.

Similarly, a 404 (Not Found) response might be generated by intermediate services rather than our backend, despite being a 4XX code.

If you encounter unexpected status codes, please notify our team.

Error Payload Schemas

Frame.io returns error details in two formats: simple and detailed. Your error handling logic should accommodate both formats.

Simple Error Schema

Here’s an example of a failed request with an incorrect client_secret:

$
curl -X POST https://api.frame.io/v2/auth/device/code \
>
    --include \
>
    --header 'x-client-version: 2.0.0' \
>
    --form 'client_id=Some-Client-ID' \
>
    --form 'client_secret=bad_secret' \
>
    --form 'scope=asset_create offline'

Response:

HTTP/2 400
...
{"error":"invalid_client"}

The simple schema contains just a single field for error identification.

Detailed Error Schema

For comparison, here’s a request without proper authorization:

$
curl -X POST https://api.frame.io/v2/devices/heartbeat \
>
    --header 'Authorization: Bearer bad-token' \
>
    --header 'x-client-version: 2.0.0' \
>
    | python -m json.tool

Response:

1
{
2
    "code": 409,
3
    "errors": [
4
        {
5
            "code": 409,
6
            "detail": "The channel you're uploading from is currently paused.",
7
            "status": 409,
8
            "title": "Channel Paused"
9
        }
10
    ],
11
    "message": "Channel Paused"
12
}

Detailed errors contain a message field that identifies the error type.

Determining Error Type

When handling Frame.io errors, first check for an error payload and then fall back to the HTTP status code if no payload is present.

Here’s a basic error handling implementation:

1
# Dict of known error codes: native errors.
2
ERROR_STATUS_MAP = {
3
    429: SlowDownError,
4
    ...
5
}
6
7
# Dict of known error messages: native errros.
8
ERROR_MESSAGE_MAP = {
9
   "Channel Paused": ChannelPausedError,
10
   "invalid_client": InvalidClientError,
11
   "slow_down": SlowDownError,
12
   ...
13
}
14
15
def _c2c_extract_error_message(response):
16
    """
17
    Gets the error message from an error payload. Returns `None` 
18
    if an error payload is not found.
19
    """
20
21
    # Try to decode the payload, if it is not JSON return `None`
22
    try:
23
        payload = response.json() 
24
    except JSONDecodeError:
25
       return None
26
27
    # Try the simple error schema first.
28
    message = payload.get("error", default=None)
29
    if message is not None:
30
        return message
31
32
    # Now try the detailed schema. Return None if we do not find one.
33
    return payload.get("message", default=None)
34
35
def _c2c_error_type_from_response(response):
36
    """
37
    Converts a bad HTTP response into an error.
38
    """
39
    error_message = _c2c_extract_error_message(response)
40
41
    # try to do a lookup of the error type by message.
42
    error_type = ERROR_MESSAGE_MAP.get(error_message, default=None) 
43
    if error_type is not None:
44
        return error_type()
45
46
    # If not, try to do a lookup by error code.
47
    error_type = ERROR_STATUS_MAP.get(response.status_code, default=None)
48
    if error_type is not None:
49
        return error_type()
50
51
    # Otherwise we are going to return an `UnknownAPIError` to signal that we
52
    # encoutnered an error from Frame.io's backend servers, but do not know the
53
    # message and/or status code.
54
    return UnknownAPIError(message=error_message)
55
56
def raise_on_frameio_error(response, expected_status):
57
    """
58
    Raises a native error from an HTTP response if the response indicates an error
59
    occured. Expected status should be the status we expect to get (200, 201, 204, 
60
    etc).
61
    """
62
63
    # If the status code is less than `400`, then it is not an error status code.
64
    if response.status < 400:
65
66
        # Check that the status code is the one we expected, otherwise raise an
67
        # error.
68
        if response.status != expected_status:
69
            raise UnexpectedStatusError(
70
                expected=expected_status, received=response.status
71
            )
72
73
        return None
74
75
    # Otherwise convert and raise a native error.
76
    raise _c2c_error_type_from_response(response)

The error lookup tables referenced in this example are provided at the end of this guide.

AWS Errors

When uploading file chunks, you interact directly with AWS S3, which has its own error format. See AWS’s common error documentation for details. As a general rule, non-fatal AWS errors should be retried at least once.

AWS errors are returned as XML:

1
<?xml version="1.0" encoding="UTF-8"?>
2
<Error>
3
  <Code>NoSuchKey</Code>
4
  <Message>The resource you requested does not exist</Message>
5
  <Resource>/mybucket/myfoto.jpg</Resource> 
6
  <RequestId>4442587FB7D0A2F9</RequestId>
7
</Error>

The Code element identifies the error type.

Retrying Errors

When to Retry

The error tables in this guide indicate which API errors should be retried. For non-API errors from I/O operations, networking libraries, or AWS, consider retrying those that may result from transient conditions. Network congestion, temporary server outages, or packet loss typically warrant retry attempts. Most networking libraries raise TimeoutError when a request takes too long, which is a prime candidate for retry.

When in Doubt, Retry Once

Computing environments can experience unpredictable issues. Even with errors that appear fatal, it’s often worth making one retry attempt. Temporary system states, hardware anomalies (such as cosmic ray bit flips), or rare memory conditions can cause seemingly fatal errors that resolve on a second attempt.

Some errors, however, should not be retried. For example, a 409: CHANNEL PAUSED response when creating an asset indicates the device is paused and should not upload. This state is deliberate and unlikely to change from a retry.

Exponential Backoff

Frame.io implements rate limiting, and exceeding these limits produces either a 429: Slow Down error or a 400 status with this payload:

HTTP/2 400
{"error":"slow_down"}

When you receive these responses, implement exponential backoff for retries. A recommended formula for calculating delay (in seconds) is:

1
delay = min(2 ** attempt / 2, 32.0)

Where attempt starts at 0. This produces delays of 0.5s, 1s, 2s, 4s, 8s, 16s, 32s, with all subsequent attempts waiting 32 seconds.

While exponential backoff is essential for rate-limiting errors, it’s also beneficial for handling network and I/O failures generally. This approach allows temporary resource constraints to resolve without additional load from your retry attempts.

Detecting Disconnected Status

When network errors occur, they may indicate that Frame.io is unreachable because:

• Your local network is down
• Frame.io’s services are experiencing issues
• An intermediate network component is failing

It’s important to detect these conditions. When an error suggests connectivity issues, implement a monitoring task that checks for service restoration and informs the user of the disconnection.

Waiting for Connection and Authorization

Design your application to avoid making unnecessary requests when the device is refreshing authorization, awaiting user authorization, or unable to reach Frame.io. This reduces network overhead and improves user experience.

Block all API calls (except to https://api.frame.io/health) when you detect a disconnected state. When connectivity issues arise, start a background task that polls the health endpoint and blocks further API calls until connectivity is restored.

Similarly, if token expiration occurs, block authorization-dependent calls until a new token is issued. If token refresh fails, alert the user to re-authenticate.

When polling for connection status, apply the same exponential backoff approach described earlier.

Request Timeouts

Configure appropriate timeout values for different types of requests:

• Default: 15 seconds for basic requests
• Authorization Refresh: 2 minutes to account for potential backend processing
• File Chunk Upload: 5 minutes to accommodate slow networks when transferring larger data

Example Retry Handler

Here’s a pseudocode implementation showing error handling with exponential backoff:

1
# List of errors we know are fatal and should not be retried.
2
FATAL_ERRORS = (
3
    ChannelPausedError,
4
    DevicesDisabledError,
5
    ...
6
)
7
8
# List of errors we know should be retried more than once.
9
RETRY_ERRORS = (
10
    TimeoutError,
11
    NotFoundError,
12
    SlowDownError,
13
    UnknownAPIError,
14
    ...
15
)
16
17
# List of errors that could be the result of Frame.io being unreachable.
18
DISCONNECTED_ERRORS = (
19
    TimeoutError,
20
    HttpClientError,
21
    ...
22
)
23
24
def retry_with_backoff(next_handler):
25
    """
26
    Middleware for retrying errors with exponential backoff.
27
    """
28
29
    def retry_handler(call, retry_count):
30
        """
31
        Handler for retrying c2c API calls with exponential backoff.
32
        """
33
34
        error = None
35
36
        # We will retry the call 8 times here, totalling 63.5 seconds +- ~32 seconds.
37
        for attempt in range(start=1, stop=retry_count + 1):
38
39
            # If we are attempting to reach an endpoint that requires authorization
40
            # we should wait unil we have valid authorization before attempting
41
            # a call. We need to do this each time in case our access_token
42
            # expires between attempts.
43
            C2C.wait_for_authorized(call)
44
45
            # Likewise, we should wait until we are connected to Frame.io to attempt
46
            # a call if we are not calling `https://api.frame.io/health`
47
            C2C.wait_for_connected(call)
48
49
            try:
50
                # Return the result on a success.
51
                return next_handler(call)
52
            except FATAL_ERRORS as error:
53
                # If we hit an error we know is fatal, raise the error without
54
                # retrying it.
55
                raise error
56
57
            except RETRY_ERRORS as error:
58
                # If we hit an error we know we should retry many times, continue,
59
                # but notify our client if we think we may have been disconnected.
60
                if type(error) in DISCONNECTED_ERRORS:
61
                    C2C.notify_disconnected()
62
63
            except BaseException as error:
64
                # Otherwise, do not retry the call more than once.
65
                if attempt > 1:
66
                    raise error
67
68
            # The delay for the next attempt should be no more than 32 seconds.
69
            # This algorithm will go: 0.5s, 1s, 2s, 4s, 8s, 16s, 32s, 32s, ...
70
            delay = min(2 ** attempt / 2, 32.0)
71
72
            # Add some randomness (jitter) to the delay (up to half the value of
73
            # the delay in either direction).
74
            delay += math.random(-delay, delay) / 2
75
76
            # Wait between retries
77
            sleep(delay)
78
79
        # If we have exhausted all retries,
80
        raise error
81
82
    return retry_handler

Error Tables

The following tables categorize Frame.io API errors and provide handling guidance. Here’s what each column represents:

message: The error payload message identifier http code: The HTTP status code error type: A conceptual error category (detailed in the descriptions section) schema: The error payload format (simple or detailed) retry: Retry recommendation (yes for multiple attempts, once for a single retry, no for fatal errors)

Asterisks (*) indicate special considerations detailed in the descriptions section.

Frame.io Error Messages

Frame.io Status Codes

AWS Errors

See AWS’s documentation for detailed descriptions.

Descriptions

AccessDenied

Returned when a user declines authorization during device pairing.

AuthorizationPending

Indicates a user hasn’t yet entered the device pairing code. Continue polling after the interval period specified in the device code response.

ChannelPaused

The device channel was paused when the asset was created. Do not attempt to upload this asset again.

ExpiredToken

The device pairing code has expired. Generate a new code and restart the pairing process.

InternalServerError

Indicates an unexpected backend issue. Retry once, and please report 500 errors to our team for investigation.

Note that some known issues return 500 errors when they should return InvalidRequest:

• Attempting to upload to a non-existent device channel
• Requesting an invalid custom chunk count

InvalidArgument

A payload parameter contained an invalid value. Verify the parameter values match API expectations.

InvalidContentType

The request’s Content-Type header is unsupported. The API generally accepts:

• form/multipart (authorization endpoints only)
• application/x-www-form-urlencoded (all endpoints)
• application/json (non-authorization endpoints)

InvalidClient

The provided credentials (client_id, client_secret, etc.) were not recognized. Verify your integration credentials.

InvalidClientVersion

The x-client-version header was either duplicated or contains an invalid semantic version.

InvalidGrant

The authorization grant type is invalid. Review the authorization guides for correct values.

InvalidRequest

The request parameters or payload format is incorrect. Verify field names and value formats.

If received during token refresh, your refresh token has expired and you must restart the authorization process.

SlowDown

You’ve exceeded request rate limits. Implement exponential backoff for subsequent requests. Note that making multiple device code requests on the same TCP connection can trigger this error—create new connections for each pairing request.

UnauthorizedClient

Typically indicates an expired or missing access_token. If you receive this error, refresh your token before retrying.

If encountered during token refresh, you must restart the authorization process and prompt the user to reconnect.

This error can also occur when accessing resources outside your device’s authorization scope or when a project has disabled C2C devices. Verify that you’ve requested appropriate scopes during authorization.

If this error occurs during token refresh, the entire authorization process must be restarted with user intervention.

Next Steps

We encourage you to contact our team with any questions and proceed to the advanced uploads guide. We look forward to supporting your integration progress.

If you haven’t already, please review the Implementing C2C: Setting Up guide before proceeding.

You’ll need the access_token obtained during the authentication and authorization process.

This guide builds on the Basic Upload guide and Advanced Uploads guide.