Hi Yuepeng Pan and other community members, I have also seen a similar issue however wrt to batch. The eventual fix could be leveraged for both streaming and batch modes.
I have described the issue observed in batch mode and can be reproduced with the following 2 ways: 1. Disable operator chaining completely 2. "pipeline.operator -chaining.chain-operators-with-different-max-parallelism": "false" // Default is true I have captured my findings and experimented with a fix for batch mode: https://docs.google.com/document/d/1TTj2ddlQTfDgtGb0ISmiKWt6R9U4RxJ59o6bULC1YtI/edit?usp=sharing On Tue, Jan 13, 2026 at 7:47 AM Yuepeng Pan <[email protected]> wrote: > Hi community, > > I would like to start a discussion around the issue described in > **FLINK-33123[1]**. > > This issue can mainly be broken down into two parts: > a). > Assuming that initially two upstream and downstream JobVertices connected > by a FORWARD edge have the same parallelism, > due to a rescale operation their parallelism becomes different. > In this case, the current strategy may produce incorrect results when > rebuilding the upstream–downstream network partition connections. > b). > Assuming that the parallelism of two upstream and downstream JobVertices is > different, > but due to a rescale operation their parallelism needs to be adjusted to be > the same. > In this scenario, it is not possible to determine the partition type after > the rescale. > > So, I'd like to share a design proposal[2] that attempts to address the > problem described in the ticket[1]. > > Thanks in advance for your time and feedback. > Looking forward to the discussion! > > > [1]https://issues.apache.org/jira/browse/FLINK-33123 > [2] > > https://docs.google.com/document/d/1e_6o4bdXcKtFL3xYxKeyKnRjR8ffsw6Z8frp3tp7u-M/edit?usp=sharing > > Best regards, > Yuepeng Pan >
