Based on my understanding of the ReentrantReadWriteLock semantics and the sink code, this could lead to a situation where the flush timer thread will re-enter the lock, and increment the lock counter to something > 1. If the second call works, and we call unlock(), there will still be a lock counter >0, so the lock won't be released. This would block the main thread from acquiring the read lock and no progress could be made for that topic partition.
I believe this line: https://github.com/Azure/kafka-sink-azure-kusto/blob/6dbd611a0fbad324cc27430ed3a61fe5e447c8b4/src/main/java/com/microsoft/azure/kusto/kafka/connect/sink/FileWriter.java#L227 should be in a finally block. Otherwise if there's an exception caught, the write lock will not be released.
Based on my understanding of the ReentrantReadWriteLock semantics and the sink code, this could lead to a situation where the flush timer thread will re-enter the lock, and increment the lock counter to something > 1. If the second call works, and we call unlock(), there will still be a lock counter >0, so the lock won't be released. This would block the main thread from acquiring the read lock and no progress could be made for that topic partition.