Error Handling

Error handling is important, especially in applications that have a lot of HTTP requests and have complicated state.

It allows for the application to handle various unanticipated behaviour in a way where the users are affected as minimally as possible.

In our Feeds SDK we differentiate between 3 types of errors:

• API Errors
• Hook errors
• Unhandled errors

WebSocket connection issues

If you’re watching a feed, it’s important to have a WebSocket connection to receive real-time updates. The client automatically creates a WebSocket connection when connecting a user. The state of the WebSocket connection can be observed via is_ws_connection_healthy client state variable.

If WebSocket connection is lost, the client will automatically retry restoring the connection. It’s typical to display a UI indicator if WebSocket connection is lost, to notify users that displayed data may be outdated.

If WebSocket connection is restored, the client will automatically refetch watched state:

• If a feed was watch-ed before the connection was lost, the feed will be refetched using getOrCreate to refresh feed metadata and latest activities
• Reading a single activity with client.activityWithStateUpdates is also refetched, as long as any of the feeds the activity is posted to is watch-ed. Usually you want to read a single activity when implementing an activity details page, and read the activity when loading the page, and call activity.dispose when leaving the page. Without calling dispose the activity may be refetched unnecessarily after WebSocket reconnection.

If refetching any feed/activity fails, an Unhandled error event is emitted.

API Errors

These are typically errors thrown from one of our APIs. They will always throw upstream in order to allow integrations to handle them as they see fit.

Hook Errors

These are errors that might occur from hooks within the SDK that do API requests (useCreateFeedsClient is one example of this). The hooks will also make sure to throw upstream, from within the render function; so that they can be caught within a React ErrorBoundary in integrations.

Unhandled Errors

These are errors that might occur within the SDK from deep within (for example if an API request is done when reacting to a WebSocket event) that can neither be thrown nor handled in a way where integrators are aware of them.

For this purpose, we’ve introduced a local event with the type of errors.unhandled.

The event will always contain an error_type property, which determines the type of unhandled error that has been dispatched.

Provided below are all of the currently available unhandled error types:

This event will always be fired on the client, meaning it can be listened to by doing client.on('errors.unhandled', (e) => { ... }).

Example

client.on("errors.unhandled", (event) => {
  const errorType = event.error_type;

  switch (errorType) {
    case UnhandledErrorType.ReconnectionReconciliation: {
      updateErrorStateStore(event.failures);
      break;
    }

    case UnhandledErrorType.SomeOtherUnhandledError: {
      displayErrorSnackbar(errorType);
      break;
    }

    default: {
      console.warn(`Unrecognized error ${errorType} has been dispatched.`);
    }
  }
});