Skip to content

[BP-2.3][FLINK-40904][FLINK-40780][runtime] Detect FORWARD parallelism mismatch correctly and make the downgrade configurable - #29548

Open
1996fanrui wants to merge 4 commits into
apache:release-2.3from
1996fanrui:FLINK-40780-2.3
Open

1996fanrui wants to merge 4 commits into
apache:release-2.3from
1996fanrui:FLINK-40780-2.3

Conversation

@1996fanrui

Copy link
Copy Markdown
Member

Backporting #29374 and #29272 to 2.3

…artitionDeploymentDescriptor

A task can only see the number of subpartitions of its outputs, which is
not the consumer parallelism on a POINTWISE edge. Pass the parallelism of
the consuming job vertices through ResultPartitionDeploymentDescriptor and
expose it via Environment#getWriterConsumerParallelism. No behavior change.

(cherry picked from commit 56dfbeb)
…ctual consumer parallelism

The FORWARD-to-REBALANCE downgrade compared the producer parallelism with
the number of subpartitions, which is not the consumer parallelism on a
POINTWISE edge. Equal parallelism > 1 was taken as a mismatch, and N -> M
with N > 1 could go undetected. Compare with the actual consumer parallelism
instead and include both values in the log.

(cherry picked from commit 96f5580)
…lism mismatch configurable

When a FORWARD edge connects a producer and consumer whose parallelism no
longer match (e.g. after a rescale via the AdaptiveScheduler or
pipeline.jobvertex-parallelism-overrides), the runtime silently replaces the
ForwardPartitioner with a RebalancePartitioner (FLINK-30213). This is safe for
append-only streams but silently reorders order-sensitive (changelog) streams,
producing incorrect results.

Add pipeline.forward-edge.parallelism-mismatch-mode to control this behavior:
- REBALANCE (default): current behavior, warn log.
- FAIL: reject the job with an exception.
- KEEP_FORWARD: keep the forward partitioner (order-preserving), warn log.

(cherry picked from commit 596c373)
…h modes

Cover every combination of scheduler (Default, Adaptive, AdaptiveBatch),
parallelism change and mismatch mode, with the new parallelism applied
either at submission via pipeline.jobvertex-parallelism-overrides or at
runtime via the resource requirements API of the AdaptiveScheduler.

(cherry picked from commit 8a369e7)
@flinkbot

flinkbot commented Oct 21, 2026 •

Copy link
Copy Markdown
Collaborator

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

@github-actions github-actions Bot added the community-reviewed PR has been reviewed by the community. label Oct 22, 2026

@MartijnVisser MartijnVisser left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have one comment.

final int producerParallelism = environment.getTaskInfo().getNumberOfParallelSubtasks();
// The number of subpartitions isn't the consumer parallelism on a POINTWISE edge, so the
// actual consumer parallelism is passed through the deployment descriptor.
final int consumerParallelism = environment.getWriterConsumerParallelism(outputIndex);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this turns a forward edge overridden from 2 to 4 into a real rebalance by default; before, only consumers 0 and 2 got data. Is that intended for a patch release?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the reveiew.

Yes, it's intended. Before this fix:

  • AdaptiveScheduler: always rebalances on a mismatch.
  • DefaultScheduler: inconsistent. 1→M became a rebalance, but 2→4 didn't, because the check used the number of subpartitions, which isn't the consumer parallelism on POINTWISE edges.

Now both schedulers rebalance, as FLINK-30213 intended. Users who need the old behavior can set KEEP_FORWARD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-reviewed PR has been reviewed by the community. target:release-2.3

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants