Hi. Thanks Yuepeng Pan and Rui for the feedback and participation! > RichSourceReaderContext is well past that, so its @Experimental tag is a > stalled promotion, not a genuine lack of stability contract.
Agree, I updated my FLIP (Motivation section) accordingly. > Is any of them a real connector today that's actually working around this? I've checked some of them, but could not find a connector working around this today, likely because the JobID is unavailable without "hacks" at this moment. > And is there any follow-up JIRA on the connector side to adopt the new > interface? I've created a follow-up umbrella ticket https://issues.apache.org/jira/browse/FLINK-39827 . I have plans to adopt the proposed API in multiple places/different repos. Happy to elaborate if it makes sense at this moment. On Tue, 2 Jun 2026 at 18:00, Rui Fan <[email protected]> wrote: > > Hey Aleksandr, > > Thanks for driving this — exposing JobInfo to the source context makes > sense, and it's already there on the sink side[1]. > > A few questions: > 1. On the "no stability contract" argument for RichSourceReaderContext: > > Per FLIP-321[2], an @Experimental API should be promoted after two > releases. RichSourceReaderContext is well past that, so its @Experimental > tag > is a stalled promotion, not a genuine lack of stability contract. The real > gaps are > that it only exists on the reader side, and that access goes through the > whole > RuntimeContext. Worth reframing the motivation around those instead. > > 2. On the use cases: > > Is any of them a real connector today that's actually working around this? > And is there any follow-up JIRA on the connector side to adopt the new > interface? > > Best, > Rui > > [1] > https://github.com/apache/flink/blob/a5a7925415bdf6f257b100cc27e9aeb19d096d04/flink-core/src/main/java/org/apache/flink/api/connector/sink2/InitContext.java#L52 > > [2] > https://cwiki.apache.org/confluence/display/FLINK/FLIP-321:+Introduce+an+API+deprecation+process > > > On Tue, Jun 2, 2026 at 4:55 PM Yuepeng Pan <[email protected]> wrote: > > > Hi Aleksandr Savonin, > > > > +1. That sounds reasonable to me. > > > > > > Best, > > Yuepeng Pan > > > > Aleksandr Savonin <[email protected]> 于2026年6月2日周二 22:21写道： > > > > > Hi everyone, > > > gently pinging this thread to see if anyone has thoughts or concerns > > > regarding this proposal. > > > > > > On Wed, 27 May 2026 at 15:57, Aleksandr Savonin <[email protected]> > > > wrote: > > > > > > > > Hi everyone, > > > > > > > > I’d like to start a discussion about FLIP-583: Expose JobInfo on > > > > Source contexts [1]. > > > > Source connectors often need job metadata (job ID, job name) for > > > > authentication, distributed tracing, metrics labeling, and other > > > > usages. SinkV2 already exposes this via `InitContext.getJobInfo()`. > > > > > > > > The current workarounds on the source side (e.g. parsing the job ID > > > > from metric group variables) are brittle/fragile and undiscoverable. > > > > The FLIP adds a `@PublicEvolving` default method `getJobInfo()` to > > > > `SourceReaderContext` and `SplitEnumeratorContext`, following the same > > > > pattern as already established in these interfaces. The runtime > > > > implementations delegate to `StreamingRuntimeContext` (reader side) > > > > and `OperatorCoordinator.Context` (enumerator side). > > > > > > > > Looking forward to your feedback. > > > > > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-583%3A+Expose+JobInfo+on+Source+contexts > > > > > > > > -- > > > > Kind regards, > > > > Aleksandr > > > > > > > > > > > > -- > > > Kind regards, > > > Aleksandr > > > > > -- Kind regards, Aleksandr
