Hello Flink Devs, I am trying to understand the behavioral contract of JobStatusChangedListener (FLIP-314) in Application Mode, to correctly fix the OpenLineage Flink integration.
In Application Mode, JobStatusChangedListenerFactory.createListener() is invoked independently at two call sites, producing two distinct instances: - EmbeddedExecutor fires the lineage creation event on Instance A — L138–142 <https://github.com/apache/flink/blob/master/flink-clients/src/main/java/org/apache/flink/client/deployment/application/executors/EmbeddedExecutor.java#L138-L142> - DefaultExecutionGraphBuilder fires the job transition event on Instance B — L147–149 <https://github.com/apache/flink/blob/master/flink-runtime/src/main/java/org/apache/flink/runtime/executiongraph/DefaultExecutionGraphBuilder.java#L147-L149> The OpenLineage integration assumes a single shared instance, where lineage context captured during graph planning is referenced upon job transition — L131–135 <https://github.com/OpenLineage/OpenLineage/blob/main/integration/flink/flink2/src/main/java/io/openlineage/flink/listener/OpenLineageJobStatusChangedListener.java#L131-L135>. With two independent instances, Instance B has no JobId set on the context. Could you clarify: 1. In the FLIP, I see "In this FLIP the JobStatusChangedListener will be in Client and JobMaster, which will report lineage information and job status independently." So is dual-instantiation in Application Mode intentional ? 2. Are listener implementations expected to be stateless, externalizing any shared state themselves? And also handle cases like Job transition events coming before the JobCreationEvent ? -Thanks M.Swapna
