Skip to content

[FLINK-40521][network] Document potential lost priority-barrier wakeup in LocalInputChannel during checkpointing-during-recovery #29057

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
1996fanrui merged 1 commit into from
Sep 2, 2026
+3 −1
Merged

[FLINK-40521][network] Document potential lost priority-barrier wakeup in LocalInputChannel during checkpointing-during-recovery #29057

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion ...c/main/java/org/apache/flink/runtime/io/network/partition/consumer/LocalInputChannel.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -666,7 +666,9 @@ private Optional<BufferAndAvailability> pullPriorityFromSubpartitionView() throw

Buffer.DataType expectedNextDataType = next.getNextDataType();
if (!expectedNextDataType.hasPriority()) {
// Reset hasPendingPriorityEvent to false if no more priority event.
// Latent lost-wakeup: this lock-free clear can clobber a concurrent set-true in
// notifyPriorityEvent(). Safe today only because Flink runs no concurrent unaligned
// checkpoints, so at most one priority barrier is ever pending.
hasPendingPriorityEvent = false;
// Correct nextDataType: if recoveredBuffers is not empty, the actual next element to
// consume is from recoveredBuffers, not from subpartitionView.
Expand Down