[jira] [Created] (FLINK-38348) Fix flushing issue for append write with buffer sort and bounded source

Shuo Cheng created FLINK-38348: -- Summary: Fix flushing issue for append write with buffer sort and bounded source Key: FLINK-38348 URL: https://issues.apache.org/jira/browse/FLINK-38348 Project: Flink

Re: [DISCUSS] Flink 1.20.3 release

+1 on this. G On Thu, Sep 11, 2025 at 3:33 AM Xuannan Su wrote: > Hello devs, > > I would like to start a discussion about the next patch release for 1.20. > The 1.20.2 version was released almost 2 months ago, and there have been > several important fixes since then. > > If there are no objec

[jira] [Created] (FLINK-38347) Checkpoint file-merging manager may delete the directory unexpectedly when some RPC messages lost

Zakelly Lan created FLINK-38347: --- Summary: Checkpoint file-merging manager may delete the directory unexpectedly when some RPC messages lost Key: FLINK-38347 URL: https://issues.apache.org/jira/browse/FLINK-38347

[jira] [Created] (FLINK-38346) JSON_QUERY returns ARRAY

dylanhz created FLINK-38346: --- Summary: JSON_QUERY returns ARRAY Key: FLINK-38346 URL: https://issues.apache.org/jira/browse/FLINK-38346 Project: Flink Issue Type: Bug Reporter: dylanhz

[DISCUSS] Flink 1.20.3 release

Hello devs, I would like to start a discussion about the next patch release for 1.20. The 1.20.2 version was released almost 2 months ago, and there have been several important fixes since then. If there are no objections to the release, I would like to volunteer as the release manager. Best reg

[jira] [Created] (FLINK-38345) HybridSource checkpoint recovery results in NPE if addSource depends on previousEnumerator from SourceSwitchContext

Matt Cuento created FLINK-38345: --- Summary: HybridSource checkpoint recovery results in NPE if addSource depends on previousEnumerator from SourceSwitchContext Key: FLINK-38345 URL: https://issues.apache.org/jira/bro

[jira] [Created] (FLINK-38343) Support store rescale history by ExecutionGraphInfoStore and query the rescale history with statistics.

RocMarshal created FLINK-38343: -- Summary: Support store rescale history by ExecutionGraphInfoStore and query the rescale history with statistics. Key: FLINK-38343 URL: https://issues.apache.org/jira/browse/FLINK-3834

Re: Re: [DISCUSS] FLIP-537: Enumerator with Global Split Assignment Distribution for Balanced Split assignment

Thanks for the explanation, Hongshun. Current pattern of handling new reader registration following: 1. put all the reader information in the SplitEnumerator context 2. notify the enumerator about the new reader registration. 3. Let the split enumerator get whatever information it wants from the c

[jira] [Created] (FLINK-38342) Support record rescale information

RocMarshal created FLINK-38342: -- Summary: Support record rescale information Key: FLINK-38342 URL: https://issues.apache.org/jira/browse/FLINK-38342 Project: Flink Issue Type: Sub-task

[jira] [Created] (FLINK-38339) Adjust the statistics-related classes for reusing in the statistical calculations of the rescale history

RocMarshal created FLINK-38339: -- Summary: Adjust the statistics-related classes for reusing in the statistical calculations of the rescale history Key: FLINK-38339 URL: https://issues.apache.org/jira/browse/FLINK-383

[jira] [Created] (FLINK-38337) Chinese translation for document PR

Scott Fauerbach created FLINK-38337: --- Summary: Chinese translation for document PR Key: FLINK-38337 URL: https://issues.apache.org/jira/browse/FLINK-38337 Project: Flink Issue Type: Improve

Flink Kubernetes Operator: New release with Flink 2.1 support

Hi Folks, Flink 2.1 has been out for a while now and the current Kubernetes Operator release (1.12.1) only supports Flink 2.0. The main branch already has support for Flink 2.2 so a release with 2.1 support seems prudent. I was wondering what barriers, other than maintainer time, prevent a new

SplitEnumeratorContext supports fixed delay async call.

Hi devs, I'd like to start a discussion on adding support for fixed-delay asynchronous calls in SplitEnumeratorContext [1]. Because it's a public API, I'm interested in your thoughts: 1. Is this functionality needed in the current design? 2. Would this require a small FLIP or a jira is enough. C