[
https://issues.apache.org/jira/browse/FLINK-40362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18113824#comment-18113824
]
Martijn Visser commented on FLINK-40362:
----------------------------------------
Two corrections to the description, now that the fix has landed.
The replay is limited to the reader's first metadata update, not every metadata
update.
{{handleSourceEvents}} captures {{!isActivelyConsumingSplits}} before the flag
flips and
replays only then. Replaying on every update lets an active reader finish
before the splits
of a newly added cluster arrive, which
{{DynamicKafkaSourceReaderTest#testActiveReaderWaitsForNewSplitsAfterMetadataChange}}
pins.
On a later metadata change the reader waits for the enumerator to signal again,
and that
re-signal is currently missing for a sub-enumerator recreated with its
partitions already
assigned, see FLINK-31006.
The ITCase link is confirmed, not a suspicion.
{{SourceTestSuiteBase#testIdleReader}}, run
through {{DynamicKafkaSourceITTest$IntegrationTests}}, hangs on unfixed main
whenever the run
leaves a subtask idle: CI jobs 99324744080 (2026-08-30, JDK 17) and
102185118941 (2026-09-08,
JDK 21) on the PR #289 branch, and 2 of 8 local runs, both of them the runs
with an idle
subtask. Whether a run has an idle subtask follows from the random topic suffix
through the
topic-hash split owner, roughly one run in twenty, so green runs prove nothing
either way.
The reader-side completion path for this case existed until cdfa328b
(kafka-3.1.0), which
replaced the {{!isNoMoreSplits && clusterReaderMap.isEmpty()}} shortcut in
{{pollNext}} with
an unconditional one, so an idle reader stopped finishing on the signal alone.
> DynamicKafkaSource idle reader never finishes when no-more-splits precedes
> the metadata update
> ----------------------------------------------------------------------------------------------
>
> Key: FLINK-40362
> URL: https://issues.apache.org/jira/browse/FLINK-40362
> Project: Flink
> Issue Type: Bug
> Components: Connectors / Kafka
> Reporter: Sylwester Lachiewicz
> Assignee: Sylwester Lachiewicz
> Priority: Minor
> Labels: pull-request-available
>
> An idle reader (a subtask with no assigned splits) that receives the
> no-more-splits signal before the {{MetadataUpdateEvent}} never forwards that
> signal to the sub-readers created by the update.
> {{DynamicKafkaSourceReader.handleSourceEvents}} guards the re-notification
> with {{!pendingSplits.isEmpty()}}, which is false in exactly this case, so
> {{notifyNoMoreSplits()}} is never re-delivered. The reader then returns
> {{NOTHING_AVAILABLE}} indefinitely and a bounded job never finishes.
> Reproduced deterministically at unit level:
> {{DynamicKafkaSourceReaderTest#testIdleReaderFinishesWhenNoMoreSplitsArrivesBeforeMetadata}}
> calls {{notifyNoMoreSplits()}} before {{handleSourceEvents(metadata)}} and
> then polls for {{END_OF_INPUT}}. On main it fails with "expected:
> END_OF_INPUT but was: NOTHING_AVAILABLE"; with the fix it passes.
> Fix: re-deliver the no-more-splits signal after processing a metadata update
> regardless of whether pending splits exist. {{notifyNoMoreSplits()}} is
> idempotent and only fires when the signal has already arrived, so this adds
> no new cross-component traffic.
> This was originally suspected of causing {{DynamicKafkaSourceITTest}}
> {{testIdleReader}} hangs in CI, but that has not been reproduced locally
> (11/11 passes on unfixed main), so the ITCase link is unconfirmed.
> Related: FLINK-40094 and FLINK-39979 touch the same reader idleness area.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
