retry

Type:

Available in: Cloud, Self-Managed

Attempts to write messages to a child output and if the write fails for any reason the message is retried either until success or, if the retries or max elapsed time fields are non-zero, either is reached.

  • Common

  • Advanced

# Common config fields, showing default values
output:
  label: ""
  retry:
    output: null # No default (required)
# All config fields, showing default values
output:
  label: ""
  retry:
    max_retries: 0
    backoff:
      initial_interval: 500ms
      max_interval: 3s
      max_elapsed_time: 0s
    output: null # No default (required)

All messages in Redpanda Connect are always retried on an output error, but this would usually involve propagating the error back to the source of the message, whereby it would be reprocessed before reaching the output layer once again.

This output type is useful whenever we wish to avoid reprocessing a message on the event of a failed send. We might, for example, have a deduplication processor that we want to avoid reapplying to the same message more than once in the pipeline.

Rather than retrying the same output you may wish to retry the send using a different output target (a dead letter queue). In which case you should instead use the fallback output type.

Fields

max_retries

The maximum number of retries before giving up on the request. If set to zero there is no discrete limit.

Type: int

Default: 0

backoff

Control time intervals between retry attempts.

Type: object

backoff.initial_interval

The initial period to wait between retry attempts.

Type: string

Default: "500ms"

backoff.max_interval

The maximum period to wait between retry attempts.

Type: string

Default: "3s"

backoff.max_elapsed_time

The maximum period to wait before retry attempts are abandoned. If zero then no limit is used.

Type: string

Default: "0s"

output

A child output.

Type: output