Hey Sushant, Thanks for the KIP. Overall, the KIP looks like a good enhancement to the Share Consumer interface and helps unlock a significant use case. A couple of questions or suggestions:
SJ1: If a record is a "poison pill" (a record that consistently causes a consumer to require a very long processing timeout), a malicious or buggy consumer could be programmed to continuously renew the lock to prevent it from ever reaching a failure state on the consumer and being moved to a REJECTED or ARCHIVED state in the broker. Unlimited renewals can create a self-inflicted, persistent Head-of-Line (HOL) blocking issue for the entire share consumer group. Are there broker-side limits (e.g., a maximum number of renewals or a maximum cumulative lock duration) that can be configured to force a difficult record to eventually transition? SJ2: This is somehow linked to the comment `SJ1`. Would it make sense to improve visibility into lock renewal activity for better debugging and operational awareness? For example, exposing broker-level metrics or diagnostics that help operators identify cases of frequent or ineffective renewals could be valuable in understanding consumer or record-level issues. These metrics may be essential for operators to debug long-running jobs, identify bottlenecks, and properly configure consumer timeouts. Regards, Sanskar On Tue, Oct 7, 2025 at 3:46 PM Sushant Mahajan <[email protected]> wrote: > I’d like to start the discussion for KIP-1222: Acquisition lock timeout > renewal in share consumer explicit mode. > > JIRA: https://issues.apache.org/jira/browse/KAFKA-19742 > KIP Wiki: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1222%3A+Acquisition+lock+timeout+renewal+in+share+consumer+explicit+mode > > Regards, > Sushant Mahajan >
