El artículo técnico explica el mecanismo interno por el cual Apache Flink gestiona los offsets de consumo en Kafka, destacando una corrección crítica para temas transaccionales. A diferencia de los consumidores estándar, Flink almacena el offset de inicio de cada partición en su estado interno, lo que permite un procesamiento exactamente una vez mediante checkpoints. Sin embargo, un fallo identificado en el issue FLINK-33484 reveló que, al leer temas con aislamiento read_committed, Flink no actualizaba correctamente el offset comprometido ante los marcadores de transacción invisibles.
El problema surge porque, aunque el consumidor de Kafka avanza su posición interna al leer los marcadores de transacción y los registros abortados, Flink solo emitía el offset del último registro procesado. Esto generaba un desfase donde el lag reportado por las herramientas de monitoreo de Kafka permanecía en 1, aunque la tarea ya estaba actualizada. La solución propuesta requiere que, al finalizar un checkpoint, Flink reconcilie el offset comprometido con la posición real del consumidor de Kafka, que incluye estos marcadores invisibles, pero sin incluir registros aún no procesados que podrían estar en la cola de fetch. Este enfoque asegura que el estado de la tarea y el progreso de Kafka queden sincronizados, eliminando falsos lag y garantizando la consistencia del estado en temas transaccionales.