Hi chia, Thanks for your reply.
The core concern is that acks=0 (fire-and-forget) is meaningless for DeleteRecords. Unlike Produce, where high-throughput writers can reasonably trade acknowledgement for latency, DeleteRecords always needs a response: the caller must know per-partition success/error and the resulting offset to make any further decision. I will update KIP for this section. Best, TaiJu Chia-Ping Tsai <[email protected]> 於 2026年5月20日週三 下午9:55寫道： > > hi TaIju > > Could you flesh out the motivation for using “LeaderOnly” instead of > “acks”? We could use acks at the RPC level to maintain flexibility, while > the Java APIs can remain strict on using a boolean. > > Best, > Chia-Ping > > > TaiJu Wu <[email protected]> 於 2026年5月20日 晚上9:21 寫道： > > > > Hi team, > > > > I would like to discuss KIP-1343: Allow opt-in leader-only > acknowledgement > > in DeleteRecords > > to enable async deleteRecords RPC. > > > > KIP: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1343%3A+Allow+opt-in+leader-only+acknowledgement+in+DeleteRecords > > > > Thanks, > > TaiJuWu >
