Handling errors and retrying

Event reliability in DevRev snap-ins

The DevRev snap-ins platform offers event reliability features to ensure smooth and resilient event processing. This document provides an overview of these features and how developers can leverage them to build reliable snap-ins.

Getting started

To start using the event reliability features in your Snap-ins, follow these steps:

  1. Update your DevRev SDK to the latest version.
  2. Define retryable errors using the FunctionExecutionError interface in your Snap-in code.
  3. Configure the retry behavior in your snap-in manifest.
  4. Handle errors appropriately in your snap-in function.

Retryable errors

Snap-ins can define retryable errors using the FunctionExecutionError interface provided by the DevRev SDK. This enables the platform to automatically retry events that encounter intermittent or transient errors, improving overall reliability.

Retry configuration

Developers can configure the retry behavior of their snap-in functions using the snap-in manifest. The following options are available:

1functions:
2 - name: function_name
3 config:
4 runtime:
5 max_retries: 5 # number of retries before failing the event
6 min_interval: 120 # interval in seconds between each retry
  • max_retries: The maximum number of retries before marking the event as failed.
  • min_interval: The minimum interval in seconds between each retry attempt. This interval may be adjusted based on the timeout of the corresponding function.

Error handling

The DevRev snap-in platform handles errors based on the ordering guarantees of the snap-in function.

For snap-in functions with relaxed ordering, non-retryable errors are marked as failed, and the errored event is propagated to the DevRev platform for tracking. Retryable errors are automatically retried based on the specified retry configuration. If the maximum number of retries is exhausted, the errored events are moved to a dead-letter queue (DLQ) for further handling.

Error interface

The DevRev SDK defines the FunctionExecutionError type to represent errors returned from the snap-in’s run function. Developers can use this type to provide additional error details and indicate whether an error is retryable.

1class FunctionExecutionError extends Error {
2 /**
3 * Toggle to determine if the event should be retried or not. If not set or set to false,
4 * the event is not retried.
5 */
6 retry: boolean;
7
8 /**
9 * Whether to retry the event payload with updated metadata
10 * that platform provides. Useful when the event payload is
11 * not in a state to be directly processed, and may need new
12 * keyrings/service account tokens or new inputs.
13 */
14 refresh?: boolean;
15
16 constructor(message: string, retry: boolean, refresh?: boolean) {
17 super(message);
18 this.retry = retry;
19 this.refresh = refresh;
20 }
21}

Example usage

Here’s an example of how to use the FunctionExecutionError in your Snap-in code:

1import { FunctionExecutionError } from '@devrev/typescript-sdk/dist/snap-ins/types';
2
3export const run = async (events: any[]) => {
4 /*
5 Put your code here to handle the event.
6 */
7 console.log('Events: ', JSON.stringify(events));
8
9 try {
10 // Your event processing logic here
11 // ...
12
13 // Retryable error
14 console.log('Retrying....');
15 const runtimeError = new FunctionExecutionError('Runtime Retryable Error', true, false);
16 throw runtimeError;
17
18 // Non-retryable error
19 // const runtimeError = new FunctionExecutionError("Runtime Non-Retryable Error", false, false);
20 // throw runtimeError;
21
22 } catch (error) {
23 if (error instanceof FunctionExecutionError) {
24 throw error;
25 } else {
26 // Handle other types of errors
27 // ...
28 }
29 }
30};
31
32export default run;

In this example, the Snap-in function’s run method processes the events and can throw a FunctionExecutionError to indicate whether the error is retryable or not. The Snap-in platform handles the error based on the retry and refresh properties set in the error object.