[waw666waw666]

If a value_deserializer/key_deserializer raises (or a per-record CRC check fails) in the middle of a fetched batch, the consumer gets stuck on the next poll():

consumer = KafkaConsumer(..., value_deserializer=json.loads)
# partition holds  {"a":1}  {"a":2}  not-json  {"a":4}
consumer.poll()   # -> {"a":1}, {"a":2}
consumer.poll()   # -> raises JSONDecodeError
consumer.poll()   # never returns, 100% CPU, timeout_ms ignored

PartitionRecords.take() raises the stored error once, but the record generator has already terminated with that exception. The partition records are still truthy and still in line at the current position, so fetched_records() keeps calling _append(), which takes 0 records each time, and while records_remaining > 0 never ends.

The usual way out is to seek past the bad record, but that didn't work either when the record sits in the middle of a batch. The broker returns the whole batch again, and the records below the fetch offset were only skipped (dropwhile) after they had been CRC-checked and deserialized, so the same record failed again.

This change:

• keeps the error on PartitionRecords and raises it on every take() until the records are drained (for example after seek()), which matches the Java client;
• skips records below the fetch offset inside _unpack_records, before validation and deserialization.

The behaviour has been there since the inline-exception handling was added in 2.2.0.

Tests: test__unpack_records_corrupted now checks that the error is raised again; new tests cover the repeated deserializer error at the PartitionRecords and fetched_records() level (the latter hangs without the fix, so it has a 10s timeout) and seeking past a bad record in the middle of a batch. All four fail on master and pass with the change. Full pytest test: 2762 passed, 68 skipped; pylint --errors-only kafka test clean.