Skip to content

Commit 2fe2c41

Browse files
committed
init docs and fixes
1 parent d9ed601 commit 2fe2c41

File tree

3 files changed

+144
-5
lines changed

3 files changed

+144
-5
lines changed

fern/docs/pages/references/inputs.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,7 @@ inputs:
7373
- value-2
7474
- value-3
7575
is_required: true
76-
default_value: value-1
76+
default_value: [value-1]
7777
ui:
7878
display_name: Enum List Picker
7979
```

fern/docs/pages/references/snap-in-configuration.mdx

Lines changed: 75 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,12 @@ This enables a lot of flexibility in the snap-in configuration page making it ea
1010
In your manifest, add the following section to enable a configuration_handler:
1111

1212
```yaml
13+
snap_kit_actions:
14+
- name: org_snap_kit_action
15+
function: org_snap_in_configuration_handler
16+
- name: user_snap_kit_action
17+
function: user_snap_in_configuration_handler
18+
1319
functions:
1420
- name: org_snap_in_configuration_handler
1521
description: Handler for processing organization configuration options.
@@ -21,15 +27,80 @@ functions:
2127
configuration_handler:
2228
organization:
2329
initializer: config_initializer
24-
snap_kit_action_name: org_snap_in_configuration_handler
30+
snap_kit_action_name: org_snap_kit_action
2531

2632
user:
2733
initializer: config_initializer
28-
snap_kit_action_name: user_snap_in_configuration_handler
34+
snap_kit_action_name: user_snap_kit_action
2935
```
3036
3137
The above YAML segment creates three functions and connects them to the configuration_handler to enable custom snap-kits to be rendered as the snap-in configuration page. The `config_initializer` function is used to generate the initial configuration options for both organization and user. The `org_snap_in_configuration_handler` and `user_snap_in_configuration_handler` functions are used to process the organization and user configuration options respectively.
3238

33-
When the snap-in configuration page is loaded, the snap-in will call the `config_initializer` function to get the initial configuration options. Further actions on the returned snap-kit will then call the `org_snap_in_configuration_handler` or `user_snap_in_configuration_handler` function to render the snap-kit for the organization or user respectively.
39+
When the snap-in configuration page is loaded, the snap-in will call the `config_initializer` function to get the initial configuration options. Further actions on the returned snap-kit will then call the `org_snap_kit_action` or `user_snap_kit_action` snap-kit action to process and update the snap-kit for the organization or user respectively.
40+
41+
The functions should always return a valid snap-kit JSON such as below:
42+
```json
43+
{
44+
"snap_kit_body": {
45+
"body": {
46+
"snaps": [
47+
{
48+
"elements": [
49+
{
50+
"action_id": "user_snap_kit_action",
51+
"action_type": "remote",
52+
"elements": [
53+
{
54+
"element": {
55+
"action_id": "select",
56+
"action_type": "client",
57+
"initial_selected_option": {
58+
"text": {
59+
"text": "Ticket",
60+
"type": "plain_text"
61+
},
62+
"value": "ticket"
63+
},
64+
"options": [
65+
{
66+
"text": {
67+
"text": "Ticket",
68+
"type": "plain_text"
69+
},
70+
"value": "ticket"
71+
},
72+
{
73+
"text": {
74+
"text": "Conversation",
75+
"type": "plain_text"
76+
},
77+
"value": "conversation"
78+
}
79+
],
80+
"type": "static_select"
81+
},
82+
"type": "input_layout"
83+
}
84+
],
85+
"submit_action": {
86+
"action_id": "next",
87+
"style": "primary",
88+
"text": {
89+
"text": "Next",
90+
"type": "plain_text"
91+
},
92+
"type": "button",
93+
"value": "next"
94+
},
95+
"type": "form"
96+
}
97+
],
98+
"type": "card"
99+
}
100+
]
101+
}
102+
}
103+
}
104+
```
105+
This will render a snap-kit with a dropdown to select between "Ticket" and "Conversation" and a "Next" button. The snap-kit will then call the `user_snap_in_configuration_handler` function when the "Next" button is clicked.
34106

35-
The functions should always return a valid snap-kit JSON.

fern/docs/pages/retry-mechanism.mdx

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
# Event Reliability in DevRev Snap-ins
2+
3+
DevRev Snap-ins platform now offers enhanced 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+
## Retryable Errors
6+
7+
Snap-ins can now define retryable errors using the `FunctionExecutionError` interface provided by the DevRev SDK. This allows the platform to automatically retry events that encounter intermittent or transient errors, improving overall reliability.
8+
9+
## Retry Configuration
10+
11+
Developers can configure the retry behavior of their Snap-in functions using the Snap-in manifest. The following options are available:
12+
13+
```yaml
14+
functions:
15+
- name: function_name
16+
config:
17+
runtime:
18+
max_retries: 5 # number of retries before failing the event
19+
min_interval: 10 # interval in minutes between each retry
20+
```
21+
22+
- `max_retries`: Specifies the maximum number of retries before marking the event as failed.
23+
- `min_interval`: Specifies the minimum interval in minutes between each retry attempt. This interval may be adjusted based on the timeout of the corresponding function.
24+
25+
## Error Handling
26+
27+
The DevRev Snap-ins platform handles errors based on the ordering guarantees of the Snap-in function:
28+
29+
For Snap-in functions with relaxed ordering, non-retryable errors will be marked as failed, and the error will be propagated to the DevRev platform for tracking. Retryable errors will be automatically retried based on the specified retry configuration. If the maximum number of retries is exhausted, the event will be moved to a dead-letter queue (DLQ) for further handling.
30+
31+
32+
## Error Interface
33+
34+
The DevRev SDK introduces the `FunctionExecutionError` type to represent errors returned from the Snap-in function's run function. Developers can use this type to provide additional error details and indicate whether an error is retryable.
35+
36+
```typescript
37+
class FunctionExecutionError extends Error {
38+
/**
39+
* Toggle to determine if the event should be retried or not. If not set or set to false,
40+
* the event will not be retried.
41+
*/
42+
retry: boolean;
43+
44+
/**
45+
* Whether to retry the event payload with updated metadata
46+
* that platform provides. Useful when the event payload is
47+
* not in a state to be directly processed, and may need new
48+
* keyrings/service account tokens or new inputs.
49+
*/
50+
refresh?: boolean;
51+
52+
constructor(message: string, retry: boolean, refresh?: boolean) {
53+
super(message);
54+
this.retry = retry;
55+
this.refresh = refresh;
56+
}
57+
}
58+
```
59+
60+
## Getting Started
61+
62+
To start using the event reliability features in your Snap-ins, follow these steps:
63+
64+
1. Update your DevRev SDK to the latest version.
65+
2. Define retryable errors using the `FunctionExecutionError` interface in your Snap-in code.
66+
3. Configure the retry behavior in your Snap-in manifest.
67+
4. Handle errors appropriately based on the ordering guarantees of your Snap-in function.
68+
{/*5. Use the provided APIs to manage and retry failed events as needed.*/}

0 commit comments

Comments
 (0)