💬 讨论 (10)
8 条回复 · 7 位参与者
讨论旨在收紧 Kafka 基于时间的发布计划，以消除每次发布时繁琐的日期讨论并优化时间安排。社区普遍支持采用固定的发布节奏，特别是特性冻结和代码冻结之间采用“3+2”周的间隔，并提出了基于 ISO 周的具体日期方案以避开主要假期。
@Matthias J. Sax: 提议建立固定的发布时间表，并建议使用 ISO 周数（第 9/25/41 周）来确定 KIP 冻结日期，以避开春节和圣诞节等假期。
@Andrew Schofield / Bill Bejeck / Ismael Juma: 支持更严格的发布规则，倾向于在 3 月、7 月和 11 月发布，并采用“3+2”冻结时间表（即特性冻结 3 周，代码冻结 2 周）。
@Chia-Ping Tsai: 支持 Matthias 的 ISO 周计划，并提议更新 Wiki 以列出未来几年的具体发布日期，以缓解社区对时间安排的焦虑。
初步达成共识采用“3+2”冻结时间表，并倾向于 Matthias 提出的基于 ISO 周的方案。下一步行动是确认具体日期并由 Chia-Ping Tsai 更新 Wiki。
5 条回复 · 5 位参与者
讨论主要围绕 Kafka 4.4.0 版本的发布时间表调整，核心议题是为避免后续 4.5 版本落在假期季，是否应将 4.4 周期延长一个月。Matthias 提议推迟 KIP 冻结日期，Bill 则提出了一个折中的时间调整方案。
@Matthias J. Sax: 若维持 4 个月发布周期，4.5 版本将撞上假期，建议将 4.4 周期延长至 5 个月，将 KIP Freeze 推迟至 7 月 15 日。
@Omnia Ibrahim: 认同假期发布的风险，支持将发布计划整体推迟至 10 月中旬，并增加一周的 KIP Freeze 时间。
@Bill Bejeck: 参考相关讨论，认为 KIP Freeze 从 6 月 15 日直接跳到 7 月 15 日跨度太大，建议折中方案定在 7 月 1 日。
尚未达成最终共识，Bill 提出了将 KIP Freeze 定于 7 月 1 日的折中建议，下一步需团队确认该时间表并更新发布计划。
5 条回复 · 4 位参与者
讨论主要围绕 KIP-1238 为 Kafka Streams 的 TopologyTestDriver 引入多分区支持功能的实现细节。参与者确认了采用构建器模式的 API 设计，解决了 null 键路由策略、状态存储访问限制及文档描述矛盾等问题，最终达成一致。
@Sebastien Viale: 提议采用构建器模式 API 以明确区分设置与执行阶段，并同意在多分区模式下对 null 键采用轮询路由，同时限制无参数的状态存储访问。
@Lucas Brutschy: 建议对 null 键使用轮询路由以更好地模拟生产环境行为，且反对从 TestRecord 的 equals/hashCode 中移除分区字段以避免潜在的测试陷阱。
@Bill Bejeck: 支持该 KIP，但指出文档中关于 null 键路由的描述存在前后矛盾，要求修正以保持一致性。
讨论已达成共识，作者将根据反馈更新 KIP（包括修正文档矛盾和调整 null 键路由逻辑），随后正式发起投票。
5 条回复 · 3 位参与者
讨论主要围绕 KIP-1313 中 `clientInstanceId` 在请求头中的处理方式，涉及 UUID 与 memberId 的转换约定及协议版本兼容性问题。鉴于利用可选标记字段进行版本控制的复杂性，提案作者最终决定放弃原方案，转而引入包含该 ID 的请求头 v3 版本。
@Jun Rao: 询问 UUID 转换为 memberId (String) 的具体约定，以确保不同客户端实现的兼容性。
@Matthias J. Sax: 认为原有的兼容性协议过于复杂，建议通过版本升级来简化，并质疑在请求体中发送 clientInstanceId 的必要性。
@Andrew Schofield: 解释了依赖可选标记字段进行版本控制的问题，并据此修改了提案，提出引入请求头 v3 版本。
KIP 已进行重大修改，引入请求头 v3 版本以解决标记字段带来的复杂性，等待社区进一步审查。
5 条回复 · 4 位参与者
讨论围绕 KIP-1327 展开，旨在解决分区扩容时可能发生的热数据丢失问题。Jun Rao 质疑该提案的动机是否充分，认为提及的时钟偏斜等风险场景较为罕见；作者随后根据反馈更新了提案，移除了“热/冷”分区术语，并强调了分区扩容是常见运维操作而非边缘情况。
@Jun Rao: 质疑 KIP 动机，认为时钟偏斜和网络重试导致的问题是罕见场景，不需要通用解决方案，建议用户使用 ConsumerRebalanceListener 自行处理。
@Chia-Ping Tsai: 建议移除“热/冷”分区术语，认为这些术语用于描述分区不自然，用户的核心诉求是不丢失活跃数据。
@Jian Fu: 支持该 KIP，指出分区扩容是常见的运维任务而非边缘情况，证明了该优化的必要性。
作者已根据社区反馈更新了 KIP 文档（包括优化动机说明和移除特定术语），讨论仍在推进中。
5 条回复 · 2 位参与者
讨论主要围绕 KIP-1335 中分区重分配的并发限制机制展开，Manan Gupta 详细解释了增量与非增量模式的运作差异及批处理轮询机制。Luke Chen 在确认模式细节后，重点质疑了批处理模式作为长时间运行进程可能阻塞调用方的问题，建议改为非阻塞设计。
@Manan Gupta: 解释了非增量模式需等待整批完成，而增量模式保持 N 个活跃任务并动态补充；确认批处理通过轮询集群状态来检测完成情况。
@Luke Chen: 建议在 KIP 中补充模式选择指南和示例，并认为默认轮询间隔（500ms）过于激进，建议增加至 1 秒以上。
@Luke Chen: 指出批处理模式会导致 AdminClient 长时间运行并阻塞脚本或 Operator，建议返回 Future 列表以支持非阻塞检查。
Manan 解释了长运行逻辑的必要性（需轮询复制状态），并指出用户仍可使用旧的非阻塞模式（execute + verify），但关于是否应调整默认行为以解决阻塞问题的讨论尚未最终定论。
4 条回复 · 2 位参与者
本次讨论围绕 PR #875 展开，旨在修复并添加 CVE-2026-41115 的安全漏洞信息，该漏洞涉及 CONSUMER_GROUP_DESCRIBE API 中的授权不当问题。经过代码审查与修改，该 PR 已被合并。
@showuon: 提交了添加 CVE-2026-41115 信息的 PR，并根据审查反馈进行了更新。
@mimaison: 对 cve-list.md 文件中新增的 CVE 内容进行了代码审查。
PR #875 已成功合并，相关 CVE 信息已更新至 Kafka 官网。
3 条回复 · 2 位参与者
该 PR 旨在将 KIP-1271（支持 Header 的状态存储）的文档从主仓库同步至 Kafka 4.3 网站分支，以补充因代码合并晚于版本发布而缺失的文档内容。主要修改涉及 Processor API、交互式查询和升级指南的相关章节。最终该 PR 已被审核并合并。
@nileshkumar3: 提交 PR 以回填 KIP-1271 文档，包括在 State Stores 中使用 Headers 的新特性及相关 API 说明。
@mjsax: 审核并合并了该 PR。
PR 已成功合并，Kafka 4.3 版本网站文档已更新包含 KIP-1271 内容。
3 条回复 · 3 位参与者
讨论主要围绕 KIP-1299 提议中新增参数的命名规范展开。Andrew Schofield 和 Chia-Ping Tsai 指出原提议的 `--message-key-range` 与现有工具参数风格不一致，建议改为 `--record-key-range`。作者黃竣陽采纳了该建议并已更新 KIP 文档。
@Andrew Schofield: 质疑 `--message-key-range` 的命名，指出工具中未使用 `--message` 前缀，倾向于使用 `--record`。
@Chia-Ping Tsai: 建议使用 `--record-key-range`，以保持与现有参数命名的一致性。
@黃竣陽: 确认收到反馈，并将参数名称更新为 `--record-key-range`。
社区达成共识，参数名称确定为 `--record-key-range`，作者已完成 KIP 更新。
3 条回复 · 2 位参与者
讨论主要关于 Kafka Streams 文档示例代码的更新位置。维护者指出 kafka-site 仓库的内容是从主仓库生成的，因此修改应在 kafka.git 中进行，否则会被覆盖。最终该 PR 被关闭，贡献者准备向正确的仓库提交新 PR。
@mjsax: kafka-site 不是文档的源文件，修改会被发布流程覆盖，需在 kafka.git 的 docs/streams/developer-guide/testing.md 处修改。
@agebhar1: 询问确认是否应修改主仓库文件并开启新 PR。
@mjsax: 确认应向 kafka.git 提交 PR，而非 kafka-site.git。
当前 PR 已关闭，下一步是向 kafka.git 仓库提交新的 PR 以修复文档。