2026-03-02 ~ 2026-03-08
本周无公告
Ferenc Csaky 提议发布 flink-connector-kafka v5.0.0，主要包含 Kafka 客户端从 3.x 升级至 4.x 等改进，并计划支持 Flink 2.1 和 2.2。社区成员普遍支持该提议，但指出需先解决测试稳定性问题及同步更新相关文档。发布者已确认将优先处理测试失败问题。
@Ferenc Csaky: 提议发布 v5.0.0，核心变更为升级 Kafka 客户端至 4.x，并自愿担任发布经理。
@Martijn Visser: 支持发布，但强调需先修复长期未成功的每周测试，确保所有支持版本的测试稳定运行。
@Bowen Li: 支持发布，并指出需更新 /flink-python 和 /docs 中的 connector 版本以解决当前结构限制。
社区初步达成发布共识，下一步行动是由发布经理 Ferenc Csaky 在未来几天内优先排查并修复测试失败问题。
Martijn Visser 提议 Flink 社区制定 AI 辅助贡献指南（如强制披露、贡献者责任制）并引入 AGENTS.md 文件以辅助 AI 编码工具。多位社区成员对此表示支持，并进一步探讨了如何优化 AI 代码审查流程及利用 AI 代理辅助回答用户问题。
@Martijn Visser: 建议采用 AI 贡献指南（要求披露工具和负责变更），并在根目录及各模块添加 AGENTS.md 文件以提供项目上下文。
@Leonard Xu: 支持提案，并建议引入 AI 代理来协助回答用户邮件列表中未被回复的问题。
@Zakelly Lan: 强调需关注 AI 生成代码在架构、性能和复用性上的短板，建议通过 GitHub 标签或机器人提醒机制优化审查流程。
社区对提案达成初步共识，下一步将着手制定具体的贡献指南和 AGENTS.md 文件内容。
Mika Naylor 发起 FLIP-567 提案，旨在引入 ProcessTableFunction (PTF) 测试工具以简化单元测试流程，避免依赖完整的 Flink 集群集成测试。讨论主要集中在测试范围界定、生命周期管理、状态快照与恢复机制以及状态后端兼容性等技术细节上。
@Mika Naylor: 提议构建轻量级测试框架以支持 PTF 的输出、状态和定时器验证；计划采纳建议，增加 AutoCloseable 支持及快照恢复功能。
@David Radley: 询问该工具的定位是仅用于单元测试还是通用验证，并关注处理时间的考量。
@Martijn Visser: 建议明确生命周期管理（open/close），增加对检查点和状态恢复的支持以捕获序列化问题，并考虑不同状态后端的兼容性。
提案作者计划根据反馈完善设计，特别是增加生命周期的自动管理（AutoCloseable）以及状态快照与恢复功能。
讨论主要围绕 FLIP-565 展开，旨在改进 ProcessTableFunctions 以处理迟到数据和状态访问。社区对提案反响积极，认可 BROADCAST_SEMANTIC_TABLE 等改进解决了实际痛点，并澄清了广播状态下的技术细节。若无异议，发起人将于周一开始投票。
@Gustavo de Morais: 支持该提案，认为 BROADCAST_SEMANTIC_TABLE 解锁了小查找表的优化场景，并赞同支持 ORDER BY 的做法。
@Ryan van Huuksloot / Timo Walther: 认同“先实现功能，再优化易用性”的策略，指出 PTFs 主要面向平台开发者，且为 AI 编写代码提供原语很重要。
@Natea Eshetu Beshada / Timo Walther: 确认了广播状态设计中允许在重新评估期间调用 collect()，以支持广播规则变更后重新发送修正结果的实用模式。
社区已达成共识，若无异议，将于周一正式启动投票流程。
讨论围绕 FLIP-495（支持 AdaptiveScheduler 记录扩缩容历史）展开，重点优化了动机描述的清晰度。David Radley 建议改进措辞并补充具体示例以明确功能价值，Yuepeng Pan 采纳建议并说明了文档编写计划。此外，Yuepeng 还明确了该功能将配合 FLIP-487 的子任务一同发布以支持查询接口。
@David Radley: 建议修改动机部分的措辞，使其更清晰地表达“提供信息以用于优化”，并请求增加激励性示例以直观展示 FLIP 的价值。
@Yuepeng Pan: 采纳措辞建议，明确初衷是提供历史和设置信息以供分析；计划在后续文档任务中补充具体优化场景示例（如根据资源等待时长调整超时参数）。
确认采纳动机描述的修改建议，将在相关文档任务中补充具体示例，并计划结合 FLIP-487 的子任务共同发布该功能。
Jaskaran 请求社区审查一个支持 DataStream providers（如 Apache Paimon）提取 LineageVertex 的 PR，以解决 FLIP-314 集成中的阻碍问题。Peter Huang 认为该改动合理，已在 PR 上留下了次要评论，目前进展顺利。
@Jaskaran Singh Kukreja: 指出当前 DataStream providers 无法提取 LineageVertex 是集成 Paimon 的阻碍，并提交了针对 table planner 的小范围修复 PR。
@Peter Huang: 认可该改动是合理的改进，并在 PR 中添加了次要评论。
PR 已获得初步认可，作者需根据 PR 上的评论进行调整后继续推进。
讨论主要针对 FLIP-504 第二阶段（Kubernetes 上的 Flink 蓝绿部署）的设计细节。Ryan van Huuksloot 对提案提出了关键反馈，特别是反对修改用户管道来实现 Gate Operator，建议改为连接器的 Mixin 模式，并强调了跨集群迁移支持和 Watermark 验证的重要性。
@Ryan van Huuksloot: 反对通过修改用户管道来使用 Gate Operator，建议将其设计为连接器实现的 Mixin，以更好地兼容 FlinkSQL。
@Ryan van Huuksloot: ConfigMap 方案应支持 Flink 作业在不同 Kubernetes 集群间的迁移，不能仅局限于集群内操作。
@Ryan van Huuksloot: 询问 Flink Kubernetes Operator 是否会验证管道使用了 Watermark，并确认空闲配置下的记录丢失问题与 Phase 2 无关。
Gate Operator 的设计是当前 FLIP 的关键点，需要优先讨论并确定其实现方案后再推进后续工作。
Yanis Djeridi 发起讨论，指出 Flink Kubernetes Operator 在处理挂起部署时未正确设置 observedGeneration，违反了 Kubernetes API 约定。他提议修改 FlinkDeployment 和 FlinkBlueGreenDeployment 的逻辑，确保在挂起状态下也能正确标记已处理的 spec 变更。
@Yanis Djeridi: 当前 FlinkDeployment 在创建即为挂起状态时，Operator 过早返回导致 observedGeneration 等状态字段未设置。
@Yanis Djeridi: FlinkBlueGreenDeployment 的状态模式中完全缺失 observedGeneration 字段，导致部署工具无法判断处理状态。
@Yanis Djeridi: 建议在挂起状态下设置 observedGeneration 和相关状态，无需部署实际资源即可符合 K8s 规范并兼容部署工具。
目前处于征集社区对提议方案的反馈阶段。
Flink 2.3 版本同步会议指出，距离功能冻结仅剩 3 周，部分 FLIP 面临无法按时完成的风险。此外，Azure CI 构建频繁失败，需要相关人员尽快修复不稳定测试以确保发布进度。
@David Anderson: 功能冻结将在 3 周后（3 月底）进行，部分 FLIP 可能无法按时完成。
@David Anderson: Azure CI 构建频繁失败，影响项目稳定性。
@David Anderson: 呼吁被指派修复不稳定测试的开发者跟进处理相关工单。
被指派修复不稳定测试的开发者需尽快跟进处理相关工单（如 FLINK-39145 等），以解决 CI 构建失败问题。
本次讨论主要针对 FLIP-557（物化表演进的数据重处理与状态保留控制）的推进策略。鉴于临近功能冻结期，Ramin Gharib 提议将原提案拆分，仅保留争议较小的 START_MODE 功能在当前 FLIP 中，而将复杂的 STATE_RETENTION 移至独立的 FLIP 进行后续讨论。此举旨在确保核心功能能按时合入即将发布的版本。
@Ramin Gharib: 建议将 START_MODE 和 STATE_RETENTION 拆分为两个独立的 FLIP。
@Ramin Gharib: START_MODE 已基本达成一致，而 STATE_RETENTION 涉及更多复杂性和边缘情况。
@Ramin Gharib: 拆分提案可避免 START_MODE 因 STATE_RETENTION 的讨论延误而错过发布冻结期。
提议拆分 FLIP，若达成共识，下一步将更新 Wiki 以反映重新划定范围的 FLIP-557，并为状态保留功能启动单独的文档。
本周新建 29 个 Issue
本周 JIRA 主要集中在连接器生态建设与 CDC 功能增强，涉及 Kafka、StarRocks、PostgreSQL 及 Iceberg 等连接器的修复与新特性支持，以及 CDC Pipeline 的转换规则优化。其次，SQL 引擎与运行时层面也有较多更新，包括 Delta Join 级联支持、常量折叠优化、状态后端修复及 SQL 函数精度扩展。此外，还涵盖了 AI 推理集成改进、JUnit5 迁移及文档链接修复等基础设施工作。