Hi Gabor, Good point for the migration.
I took a brief look. I thought the `RuntimeContext` is too powerful and might not be suitable to expose on \@Public API. Is it possible to introduce another 'rich' code path just like the difference between `RichInputFormat` and `InputFormat`, and keep that internal? WDYT Best, Zakelly On Thu, May 22, 2025 at 6:30 PM Gabor Somogyi <gabor.g.somo...@gmail.com> wrote: > Hi All, > > I've just had a look at it how it would be possible to migrate state > processor API from source v1 to source v2 API. > > The whole concept in the state processor API actual implementation is based > on to get > RuntimeContext from RichInputFormat [1] which then allows us to access > state backend, > keyed state store, etc... > > Since RuntimeContext is not exposed on source v2 API the question is > obvious. > Does it make sense to expose it on SourceReaderContext [2] ? > > If somebody has better idea then please share. > > [1] > > https://github.com/apache/flink/blob/4c77daaf3554446e67f6b75ac18d54da84208b9a/flink-libraries/flink-state-processing-api/src/main/java/org/apache/flink/state/api/input/KeyedStateInputFormat.java#L156 > [2] > > https://github.com/apache/flink/blob/master/flink-core/src/main/java/org/apache/flink/api/connector/source/SourceReaderContext.java > > BR, > G >
