[GH] (flink-connector-kafka/FLINK-40586-signal-no-more-splits-once): Workflow run "Flink Connector Kafka CI" failed!

[GitBox <gi...@apache.org>]

The GitHub Actions job "Flink Connector Kafka CI" on flink-connector-kafka.git/FLINK-40586-signal-no-more-splits-once has failed.
Run started by GitHub user vbhanuchander-lang (triggered by vbhanuchander-lang).

Head commit for run:
505247adaba41c9a5d7f872121465a85dc0f0a7e / Bhanu Chander Vallabaneni <v....@gmail.com>
[FLINK-40586][Connectors/Kafka] Signal no more splits to each reader once per registration

DynamicKafkaSourceEnumerator.handleNoMoreSplits() signalled every registered
reader on every invocation, and it is reached from addReader, addSplitsBack and
tryCompletePendingReaderRegistration. A reader that already finished on an
earlier signal is therefore signalled again when another reader registers, or
when any reader is reset -- SourceCoordinator.subtaskReset calls addSplitsBack
for every reset subtask, with an empty list for a reader that owned no splits.
NoMoreSplitsEvent is not loss tolerant, so delivering it to a task already in
FINISHED fails the job with "An OperatorEvent from an OperatorCoordinator to a
task was lost", which is the DynamicKafkaSourceITTest.testIdleReader failure
seen in CI.

Track which subtasks have been signalled and skip them. The set is cleared in
two places, which together define the generation a signal belongs to:

- addReader, because registration is the point at which a new attempt of a
  reader becomes addressable; without this a restarted reader would never be
  told and the job would not finish.
- where a metadata change closes and recreates the sub enumerators, because
  each new sub enumerator signals again for its new assignments while the
  reader has closed and recreated its sub readers. Without clearing there, a
  bounded job would hang after a metadata change once FLINK-31006 restores
  that re-signal.

Generated-by: Claude Code (Opus 5)

Report URL: https://github.com/apache/flink-connector-kafka/actions/runs/34550316096

With regards,
GitHub Actions via GitBox