Thanks for driving this proposal forward! This addresses a real pain point we've been hearing about for a while.
Many of our users rely on AsyncTableFunction or Lookup Join to implement custom external service calls and data fetching, typically for RAG or LLM inference scenarios. Due to the inherent instability of these external services, timeouts occur occasionally, and users want to apply fallback strategies (e.g., falling back to a local rule-based model) rather than failing the entire job. However, this hasn't been achievable so far — the hard-coded TimeoutException behavior introduces stability risks, forcing users to keep increasing the timeout value to absurd levels and work around the issue in various hacky ways. Worse, each user tends to hit this pitfall independently before realizing the limitation. Adding a timeout interface not only addresses this pain point, but also aligns the API contract between AsyncTableFunction and AsyncFunction, avoiding unnecessary confusion for users. Big +1 from our side — looking forward to seeing this land. On Mon, May 25, 2026 at 7:53 PM Xia Sun <[email protected]> wrote: > Hi Kui.Yuan, > > Thanks for driving this! > > In our production practice, the asynchronous I/O capability of > AsyncTableFunction has shown excellent performance in > batch LLM inference scenarios. We urgently need a custom timeout UDF > for this use case. It would help us handle inference requests that > time out—especially long-context requests—more precisely, and avoid > excessive retries that could otherwise block downstream data. > > +1 to this proposal. > > Best, > > Xia > > Kui Yuan <[email protected]> 于2026年5月22日周五 11:21写道： > > > Hi All, > > > > I'd like to open a discussion for FLIP-580: AsyncTableFunction supports > > user-defined timeout handling logic [1]. > > > > An increasing number of users are leveraging AsyncTableFunction to invoke > > remote inference clusters. Such invocations are essentially remote > > inference requests, which are far more prone to timeouts than regular I/O > > operations. Users expect to be able to define custom handling logic when > a > > timeout occurs — for example, falling back to default data or > accumulating > > failure statistics — rather than having a TimeoutException thrown > directly > > and causing the entire job to fail. > > > > > > This FLIP proposal allow users to define custom timeout handling logic > > inside AsyncTableFunction. > > > > I've already discussed the implementation details with @Luogen offline, > and > > there's a POC attached [2]. > > > > > > Looking forward to your feedback. > > > > Bests, > > Kui.Yuan > > > > [1]: > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-580%3A+AsyncTableFunction+supports+user-defined+timeout+handling+logic > > > > [2]: > > > > > https://github.com/yuchengxin/flink/commit/5a46cd05c48e41a582271dcb9d9842e330871a0b > > >
