fix(state): trim noisy WARN in RemovedPartitionState to topic-partition + size + epoch

[Vishal Kumar Singh (singhvishalkr)]

Fixes #631

Description

When a large number of topic-partitions are reassigned away from a consumer (e.g. during a rebalance), RemovedPartitionState#maybeRegisterNewPollBatchAsWork emits one WARN per dropped batch that dumps the entire EpochAndRecordsMap.RecordsAndEpoch:

https://github.com/confluentinc/parallel-consumer/blob/master/parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/state/RemovedPartitionState.java#L67-L69

// no-op
log.warn("Dropping polled record batch for partition no longer assigned. WC: {}", recordsAndEpoch);

Because RecordsAndEpoch carries the full List<ConsumerRecord<K,V>>, the resulting line can be many KB long. Common log tooling (Datadog, Splunk, CloudWatch) truncates at a fixed byte budget, which silently chops the most actionable part (topic-partition and epoch) out of the log.

Fix

Split the log into two statements, matching the pattern already used elsewhere in the project where detailed state is logged at DEBUG:

• WARN: concise topic-partition (N records, epoch E) — short, grep-friendly, survives log-tooling truncation.
• DEBUG (guarded by log.isDebugEnabled()): the full RecordsAndEpoch for deep troubleshooting when operators opt in.

The no-op behaviour, counts, and public API are completely unchanged; only the log output format is restructured.

Example before/after

Before (single ~5 KB line truncated to ~1 KB by log tool):

WARN Dropping polled record batch for partition no longer assigned. WC: EpochAndRecordsMap.RecordsAndEpoch(topicPartition=topic-7, epochOfPartitionAtPoll=42, records=[ConsumerRecord(topic = topic, partition = 7, leaderEpoch = 5, offset = 1234, CreateTime = 1708459200000, serialized key size = 12, serialized value size = 248, headers = RecordHeaders(headers = [], isReadOnly = false), key = k-1234, value = v-...[TRUNCATED]

After:

WARN Dropping polled record batch for partition no longer assigned: topic-7 (128 records, epoch 42)
DEBUG Full dropped batch for topic-7: EpochAndRecordsMap.RecordsAndEpoch(...)   ← only if debug is on

Checklist

• Documentation (if applicable) — not applicable; log-format change only, no public API or user-facing doc references this line.
• Changelog — this is a log-output restructuring; no behavioural change. Happy to add a CHANGELOG entry in whatever format the project prefers if a maintainer would like one.

Test plan

• Existing RemovedPartitionState / partition-rebalance tests still pass; no behavioural assertions depend on the exact WARN text.
• Manually verified the new format uses the Lombok @Value-generated getTopicPartition(), getRecords(), and getEpochOfPartitionAtPoll() accessors on the inner RecordsAndEpoch class in EpochAndRecordsMap.

[Antony Stubbs (astubbs)]

Vishal Kumar Singh (@singhvishalkr) - the maintained fork shipped this shape in v0.6.0.0: the dropped-batch WARN names the partition, the batch size and the epochs, and the full batch moved to DEBUG (astubbs#203, astubbs#428). Thank you for the report and the patch; the fork is where the work continues.

The coordinates changed with the fork - on Maven Central it is now:

<dependency>
    <groupId>bz.stub.parallelconsumer</groupId>
    <artifactId>parallel-consumer-core</artifactId>
    <version>0.6.0.0</version>
</dependency>

(parallel-consumer-vertx, parallel-consumer-reactor and parallel-consumer-mutiny likewise.) The Java package is bz.stub.parallelconsumer too, so imports change with it - one command rewrites them (GNU sed; on macOS use sed -i ''):

find . -name '*.java' -exec sed -i 's/io\.confluent\.parallelconsumer/bz.stub.parallelconsumer/g' {} +