The two values `event` and `row` in the offset denote the number of events and the number of rows to skip in the last event respectively.

When the streaming starts after a task re-start, the expectation is for these values to be adhered to. But this is not correctly implemented for the case where transaction compression is enabled.

When a compressed transaction having large number of events is deserialized and read, the counter which tracks the number of events to be skipped is not incremented. Hence, unexpectedly large number of events could be discarded, which is not correct.

https://github.com/debezium/debezium/blob/main/debezium-connector-binlog/src/main/java/io/debezium/connector/binlog/BinlogStreamingChangeEventSource.java#L819-L840 is the culprit