Details
-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
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.