Hi Muhammet, Thanks for the feedback. > Could you please add more here why it is harder? Would the > `completeExceptionally` > method be related to it? Maybe you can add usage example for it also. >
this is mainly due to the current implementation of fatal exception failures which depends on base `getFatalExceptionConsumer` method that is decoupled from the actual called method `submitRequestEntries`, Since this is now not the primary concern of the FLIP, I have removed it from the motivation so that the scope is defined around introducing the timeout configuration. > Should we add a list of possible connectors that this FLIP would improve? Good call, I have added under migration plan. Best Regards Ahmed Hamdy On Mon, 6 May 2024 at 08:49, Muhammet Orazov <mor+fl...@morazow.com> wrote: > Hey Ahmed, > > Thanks for the FLIP! +1 (non-binding) > > > Additionally the current interface for passing fatal exceptions and > > retrying records relies on java consumers which makes it harder to > > understand. > > Could you please add more here why it is harder? Would the > `completeExceptionally` > method be related to it? Maybe you can add usage example for it also. > > > we should proceed by adding support in all supporting connector repos. > > Should we add list of possible connectors that this FLIP would improve? > > Best, > Muhammet > > > On 2024-04-29 14:08, Ahmed Hamdy wrote: > > Hi all, > > I would like to start a discussion on FLIP-451[1] > > The proposal comes on encountering a couple of issues while working > > with > > implementers for Async Sink. > > The FLIP mainly proposes a new API similar to AsyncFunction and > > ResultFuture as well as introducing timeout handling for AsyncSink > > requests. > > The FLIP targets 1.20 with backward compatible changes and we should > > proceed by adding support in all supporting connector repos. > > > > 1- > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-451%3A+Refactor+Async+Sink+API > > Best Regards > > Ahmed Hamdy >
