[
https://issues.apache.org/jira/browse/FLINK-21570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306270#comment-17306270
]
Stephan Ewen commented on FLINK-21570:
--------------------------------------
I think in the past we didn't consider this a factor stability, these Flink
core interfaces that could be theoretically implemented by users, so that
adding a method is breaking. In that case also, the class should be
{{@PublicEvolving}}, not the method, because the breaking factor comes from
implementing the interface.
In the end, I have a slight preference to solve this via japicmp ignores (after
resolving FLINK-21626), rather than an annotation, because PublicEvolving tends
to kind of signal the wrong thing here (that the method might change in the
future).
> Add Job ID to RuntimeContext
> ----------------------------
>
> Key: FLINK-21570
> URL: https://issues.apache.org/jira/browse/FLINK-21570
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Task
> Reporter: Roman Khachatryan
> Assignee: Roman Khachatryan
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.0
>
>
> (the issue added retroactively after the PR was merged for reference)
>
> There are some cases (e.g.
> [1|http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/How-to-get-flink-JobId-in-runtime-td36756.html],
> 2) when job ID needs to be accessed from the user code (function).
> Existing workarounds doesn't look clean (reliable).
>
> One solution discussed offline is to add {{Optional<JobID>}} to the
> {{RuntimeContext}} (the latter already contains some information of the same
> level, such as subtask index).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
