[
https://issues.apache.org/jira/browse/FLINK-40093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094572#comment-18094572
]
Efrat Levitan edited comment on FLINK-40093 at 7/8/26 1:03 PM:
---------------------------------------------------------------
Thank you [~stevenpoor] for looking into the issue and offering help!
The problem is a little more chronic, if we remove the split from
{{currentlyIdleSplits}} outside {{SourceOperator.updateCurrentSplitIdle,}} the
watermark generator [will
never|https://github.com/apache/flink/blob/master/flink-core/src/main/java/org/apache/flink/api/common/eventtime/WatermarksWithIdleness.java#L76-L77]
send another idle status and we might hold on the watermark waiting on this
split forever.
IMO we could tackle this by allowing idle splits to be resumed (while
preserving their idle status)
You are welcome to review the PR and let me know what you think.
was (Author: JIRAUSER302736):
Thank you [~stevenpoor] for looking into the issue and offering help!
The problem is a little more chronic, if we remove the split from
{{currentlyIdleSplits}} outside {{SourceOperator.updateCurrentSplitIdle,}} the
watermark generator [will
never|https://github.com/apache/flink/blob/master/flink-core/src/main/java/org/apache/flink/api/common/eventtime/WatermarksWithIdleness.java#L76-L77]
send another idle status and we might hold on the watermark waiting on this
split forever.
IMO we could tackle this by allowing idle splits to be marked paused (while
preserving their idle status)
You are welcome to review the PR and let me know what you think.
> Race condition between watermark alignment and idleness detection locks split
> in idle
> -------------------------------------------------------------------------------------
>
> Key: FLINK-40093
> URL: https://issues.apache.org/jira/browse/FLINK-40093
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Task
> Reporter: Efrat Levitan
> Assignee: Efrat Levitan
> Priority: Major
> Labels: pull-request-available
>
> Usually pauseOrResumeSplits pauses idleness timer for the split so it isn't
> marked idle while paused. However with low idleness timeout (observed with
> 1s) + low allowed WM drift, a race condition could cause paused splits to
> never resume though they have records:
> # A split becomes paused due to too advanced records.
> # pauseOrResumeSplits pauses the split.
> # pauseOrResumeSplits reaches to pause the split idleness clock but is
> \{idlenessTimeout} too late, and the split becomes idle.
> # The watermark advances but the split is excluded from the watermark
> alignment check due to its idleness.
> # More records arrive but the split is paused at the connector level so they
> aren't processed, nor seen by watermarkGenerator so it still considers the
> split idle
> A possible fix could be preserving the part where idle splits are excluded
> from alignment pause (to not override their idle status) while allowing
> alignment check to resume splits even if they are currently idle. They are
> considered idle until they emit the next record.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
