github.com/Jeffail/benthos/v3@v3.65.0/website/docs/components/outputs/retry.md (about)

     1  ---
     2  title: retry
     3  type: output
     4  status: stable
     5  categories: ["Utility"]
     6  ---
     7  
     8  <!--
     9       THIS FILE IS AUTOGENERATED!
    10  
    11       To make changes please edit the contents of:
    12       lib/output/retry.go
    13  -->
    14  
    15  import Tabs from '@theme/Tabs';
    16  import TabItem from '@theme/TabItem';
    17  
    18  
    19  Attempts to write messages to a child output and if the write fails for any
    20  reason the message is retried either until success or, if the retries or max
    21  elapsed time fields are non-zero, either is reached.
    22  
    23  
    24  <Tabs defaultValue="common" values={[
    25    { label: 'Common', value: 'common', },
    26    { label: 'Advanced', value: 'advanced', },
    27  ]}>
    28  
    29  <TabItem value="common">
    30  
    31  ```yaml
    32  # Common config fields, showing default values
    33  output:
    34    label: ""
    35    retry:
    36      output: {}
    37  ```
    38  
    39  </TabItem>
    40  <TabItem value="advanced">
    41  
    42  ```yaml
    43  # All config fields, showing default values
    44  output:
    45    label: ""
    46    retry:
    47      max_retries: 0
    48      backoff:
    49        initial_interval: 500ms
    50        max_interval: 3s
    51        max_elapsed_time: 0s
    52      output: {}
    53  ```
    54  
    55  </TabItem>
    56  </Tabs>
    57  
    58  All messages in Benthos are always retried on an output error, but this would
    59  usually involve propagating the error back to the source of the message, whereby
    60  it would be reprocessed before reaching the output layer once again.
    61  
    62  This output type is useful whenever we wish to avoid reprocessing a message on
    63  the event of a failed send. We might, for example, have a dedupe processor that
    64  we want to avoid reapplying to the same message more than once in the pipeline.
    65  
    66  Rather than retrying the same output you may wish to retry the send using a
    67  different output target (a dead letter queue). In which case you should instead
    68  use the [`fallback`](/docs/components/outputs/fallback) output type.
    69  
    70  ## Fields
    71  
    72  ### `max_retries`
    73  
    74  The maximum number of retries before giving up on the request. If set to zero there is no discrete limit.
    75  
    76  
    77  Type: `int`  
    78  Default: `0`  
    79  
    80  ### `backoff`
    81  
    82  Control time intervals between retry attempts.
    83  
    84  
    85  Type: `object`  
    86  
    87  ### `backoff.initial_interval`
    88  
    89  The initial period to wait between retry attempts.
    90  
    91  
    92  Type: `string`  
    93  Default: `"500ms"`  
    94  
    95  ### `backoff.max_interval`
    96  
    97  The maximum period to wait between retry attempts.
    98  
    99  
   100  Type: `string`  
   101  Default: `"3s"`  
   102  
   103  ### `backoff.max_elapsed_time`
   104  
   105  The maximum period to wait before retry attempts are abandoned. If zero then no limit is used.
   106  
   107  
   108  Type: `string`  
   109  Default: `"0s"`  
   110  
   111  ### `output`
   112  
   113  A child output.
   114  
   115  
   116  Type: `output`  
   117  Default: `{}`  
   118  
   119