Distinguish fetched position, committed next offset and completed business work
Fence stale completions with a per-assignment generation
Drain one in-flight record per partition without blocking unrelated partitions
Preserve a generation tombstone after revoke so delayed callbacks stay stale
A rebalance changes ownership, not completed work
When a partition is revoked, the old consumer must stop admitting records for it and drain or cancel in-flight work before handing it off. A task detached from the poll loop can finish after a new owner starts, so the application needs an assignment generation or cancellation token at its completion boundary. Stable membership reduces movement but does not remove revoke, lost-partition or failure cases.
Commit the next record only after the effect
Kafka commits the offset of the next record to consume. Committing a fetched position before its business effect can skip work; committing after the effect can replay it. The previous mission makes replay safe with an atomic effect plus inbox identity. This mission adds the ownership fence: only the current generation may publish progress, and each partition stays sequential while other partitions continue independently.
CHECKPOINT
A consumer revokes a partition while a detached handler is still running. Which controls belong in the safe handoff? Select every required control.
Select every applicable option. Credit requires an exact set match.
ISOLATED RUST 1.96
src/lib.rsEDIT
02 / DEBUGGING
Find and fix the defect
Repair RebalanceGate. Assignments must reject invalid positions and non-increasing generations; stale revoke must not remove a newer owner; only one record may be in flight per partition; replayed or uncommittable offsets must not start; and completion must match the current generation plus in-flight offset before advancing to offset + 1.