|
| 1 | +# Event reliability in DevRev snap-ins |
| 2 | + |
| 3 | +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. |
| 4 | + |
| 5 | +## Getting started |
| 6 | + |
| 7 | +To start using the event reliability features in your Snap-ins, follow these steps: |
| 8 | + |
| 9 | +1. Update your DevRev SDK to the latest version. |
| 10 | +2. Define retryable errors using the `FunctionExecutionError` interface in your Snap-in code. |
| 11 | +3. Configure the retry behavior in your snap-in manifest. |
| 12 | +4. Handle errors appropriately in your snap-in function. |
| 13 | + |
| 14 | +## Retryable errors |
| 15 | + |
| 16 | +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. |
| 17 | + |
| 18 | +## Retry configuration |
| 19 | + |
| 20 | +Developers can configure the retry behavior of their snap-in functions using the snap-in manifest. The following options are available: |
| 21 | + |
| 22 | +```yaml |
| 23 | +functions: |
| 24 | + - name: function_name |
| 25 | + config: |
| 26 | + runtime: |
| 27 | + max_retries: 5 # number of retries before failing the event |
| 28 | + min_interval: 120 # interval in seconds between each retry |
| 29 | +``` |
| 30 | +
|
| 31 | +- `max_retries`: The maximum number of retries before marking the event as failed. |
| 32 | +- `min_interval`: The minimum interval in seconds between each retry attempt. This interval may be adjusted based on the timeout of the corresponding function. |
| 33 | + |
| 34 | +## Error handling |
| 35 | + |
| 36 | +The DevRev snap-in platform handles errors based on the ordering guarantees of the snap-in function. |
| 37 | + |
| 38 | +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. |
| 39 | + |
| 40 | +## Error interface |
| 41 | + |
| 42 | +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. |
| 43 | + |
| 44 | +```typescript |
| 45 | +class FunctionExecutionError extends Error { |
| 46 | + /** |
| 47 | + * Toggle to determine if the event should be retried or not. If not set or set to false, |
| 48 | + * the event is not retried. |
| 49 | + */ |
| 50 | + retry: boolean; |
| 51 | +
|
| 52 | + /** |
| 53 | + * Whether to retry the event payload with updated metadata |
| 54 | + * that platform provides. Useful when the event payload is |
| 55 | + * not in a state to be directly processed, and may need new |
| 56 | + * keyrings/service account tokens or new inputs. |
| 57 | + */ |
| 58 | + refresh?: boolean; |
| 59 | +
|
| 60 | + constructor(message: string, retry: boolean, refresh?: boolean) { |
| 61 | + super(message); |
| 62 | + this.retry = retry; |
| 63 | + this.refresh = refresh; |
| 64 | + } |
| 65 | +} |
| 66 | +``` |
| 67 | + |
| 68 | +## Example usage |
| 69 | + |
| 70 | +Here's an example of how to use the `FunctionExecutionError` in your Snap-in code: |
| 71 | + |
| 72 | +```typescript |
| 73 | +import { FunctionExecutionError } from '@devrev/typescript-sdk/dist/snap-ins/types'; |
| 74 | +
|
| 75 | +export const run = async (events: any[]) => { |
| 76 | + /* |
| 77 | + Put your code here to handle the event. |
| 78 | + */ |
| 79 | + console.log('Events: ', JSON.stringify(events)); |
| 80 | +
|
| 81 | + try { |
| 82 | + // Your event processing logic here |
| 83 | + // ... |
| 84 | +
|
| 85 | + // Retryable error |
| 86 | + console.log('Retrying....'); |
| 87 | + const runtimeError = new FunctionExecutionError('Runtime Retryable Error', true, false); |
| 88 | + throw runtimeError; |
| 89 | +
|
| 90 | + // Non-retryable error |
| 91 | + // const runtimeError = new FunctionExecutionError("Runtime Non-Retryable Error", false, false); |
| 92 | + // throw runtimeError; |
| 93 | +
|
| 94 | + } catch (error) { |
| 95 | + if (error instanceof FunctionExecutionError) { |
| 96 | + throw error; |
| 97 | + } else { |
| 98 | + // Handle other types of errors |
| 99 | + // ... |
| 100 | + } |
| 101 | + } |
| 102 | +}; |
| 103 | +
|
| 104 | +export default run; |
| 105 | +``` |
| 106 | + |
| 107 | +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. |
0 commit comments