Uploaded image for project: 'Debezium'
  1. Debezium
  2. DBZ-4179

Pluggable error handler

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Unresolved
    • Major
    • 1.9-backlog
    • None
    • core-library
    • None
    • False
    • False

    Description

      Currently, the actual implementation of the ErrorHandler used by a specific connector task is hardcoded in the task. It makes it challenging to implement custom error handling logic.

      Whether or not a given exception is retriable may depend on a specific use case. Normally, if the source database doesn't exist, it's considered a non-retriable error. But in a multi-tenant scenario like the one described in DBZ-2975, the databases may come and go by design which shouldn't make the connector task fail.

      It would be nice to have an API to define whether or not a given error is retriable which could be plugged in instead of or combined with the default implementation.

      Note that currently the ErrorHandler class impelemens the actual error handling logic and defines an empty implementation of isRetriable that the connectors usually override. It looks like isRetriable deserves its own interface.

      Attachments

        Activity

          People

            Unassigned Unassigned
            sergeimorozov Sergei Morozov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: