Github user StephanEwen commented on a diff in the pull request: https://github.com/apache/flink/pull/5977#discussion_r188725700 --- Diff: flink-core/src/main/java/org/apache/flink/api/common/functions/RuntimeContext.java --- @@ -71,6 +71,17 @@ @PublicEvolving MetricGroup getMetricGroup(); + /** + * Returned value is guaranteed to be unique between operators within the same job and to be + * stable and the same across job submissions. + * + * <p>This operation is currently only supported in Streaming (DataStream) contexts. + * + * @return String representation of the operator's unique id. + */ + @PublicEvolving + String getOperatorUniqueID(); --- End diff -- I am still much in favor of not exposing this in the RuntimeContext: - Having the state accesses in the RuntimeContext was a necessity of that moment, because there was no `initializeState()` and it is crucial to be exposed to users. - This operatorID is not crucial to be exposed to users, hence a very different case to me. - It is super easy to expose it later, it is much harder (even if marked as PublicEvolving) to hide it later. For a quick move, not exposing an addition publicly should always be the default choice, also beyond this specific case here.
---