drop_on

Available in: Cloud, Self-Managed

Attempts to write messages to a child output and if the write fails for one of a list of configurable reasons the message is dropped (acked) instead of being reattempted (or nacked).

# Config fields, showing default values
output:
  label: ""
  drop_on:
    error: false
    error_patterns: [] # No default (optional)
    back_pressure: 30s # No default (optional)
    output: null # No default (required)

Regular Redpanda Connect outputs will apply back pressure when downstream services aren’t accessible, and Redpanda Connect retries (or nacks) all messages that fail to be delivered. However, in some circumstances, or for certain output types, we instead might want to relax these mechanisms, which is when this output becomes useful.

Fields

error

Whether messages should be dropped when the child output returns an error of any type. For example, this could be when an http_client output gets a 4XX response code. In order to instead drop only on specific error patterns use the error_matches field instead.

Type: bool

Default: false

error_patterns

A list of regular expressions (re2) where if the child output returns an error that matches any part of any of these patterns the message will be dropped.

Type: array

# Examples

error_patterns:
  - and that was really bad$

error_patterns:
  - roughly [0-9]+ issues occurred

back_pressure

An optional duration string that determines the maximum length of time to wait for a given message to be accepted by the child output before the message should be dropped instead. The most common reason for an output to block is when waiting for a lost connection to be re-established. Once a message has been dropped due to back pressure all subsequent messages are dropped immediately until the output is ready to process them again. Note that if error is set to false and this field is specified then messages dropped due to back pressure will return an error response (are nacked or reattempted).

Type: string

# Examples

back_pressure: 30s

back_pressure: 1m

output

A child output to wrap with this drop mechanism.

Type: output

Examples

  • Dropping failed HTTP requests

  • Dropping from outputs that cannot connect

In this example we have a fan_out broker, where we guarantee delivery to our Kafka output, but drop messages if they fail our secondary HTTP client output.

output:
  broker:
    pattern: fan_out
    outputs:
      - kafka:
          addresses: [ foobar:6379 ]
          topic: foo
      - drop_on:
          error: true
          output:
            http_client:
              url: http://example.com/foo/messages
              verb: POST

Most outputs that attempt to establish and long-lived connection will apply back-pressure when the connection is lost. The following example has a websocket output where if it takes longer than 10 seconds to establish a connection, or recover a lost one, pending messages are dropped.

output:
  drop_on:
    back_pressure: 10s
    output:
      websocket:
        url: ws://example.com/foo/messages