Explain seek(), seekToBeginning(), and seekToEnd() — how do they work and when does the new position take effect?

## The fetch position Every assigned partition has a **fetch position** (also called the *current position*) — the offset of the next record `poll()` will return. Normally this advances automatically as you consume. The seek family lets you set it manually. ## The three methods - **`seek(TopicPartition partition, long offset)`** — set the position to an exact offset. The next `poll()` fetches starting at that offset. There is also an overload taking `OffsetAndMetadata`. - **`seekToBeginning(Collection<TopicPartition>)`** — set the position to the **first available** offset (oldest retained record). An empty collection means *all currently assigned* partitions. - **`seekToEnd(Collection<TopicPartition>)`** — set the position to the **end** offset (one past the last record / the high watermark for that partition), so you only read records produced after this point. ## When does it take effect? (the lazy evaluation gotcha) These calls do **not** synchronously talk to the broker. `seekToBeginning`/`seekToEnd` just mark the partition as 'needs reset to beginning/end'; the actual offsets are resolved by an RPC on the **next `poll()`**. Consequently: - Calling `position()` right after `seekToEnd()` may trigger that resolution (it can block), but you should not assume the seek 'happened' the instant you called it. - The new position is only used the next time you `poll()`. ## Preconditions The partition must be **assigned** to this consumer: - With `subscribe()` (group management), assignment happens during a rebalance. You can only seek partitions you actually own — the natural place is inside `ConsumerRebalanceListener.onPartitionsAssigned`, or after a `poll()` returns and you've confirmed assignment. - With `assign()` (manual assignment, no group coordination), you own the partitions immediately and can seek right away. Seeking a partition you don't own throws `IllegalStateException`. ## Relationship to auto.offset.reset and commits - **seek overrides auto.offset.reset.** Once you explicitly position a partition, the reset policy is irrelevant for it. - **seek does NOT commit.** It changes only the in-memory read position. If you want that position to survive a restart/rebalance under group management, you must commit (or store it externally and re-seek). This is the foundation of the 'store offsets in your own datastore' pattern: on `onPartitionsAssigned`, look up your stored offset and `seek()` to it, ignoring `__consumer_offsets`. ## Typical uses - Replaying from a known offset after a bug fix. - Skipping a poison record by `seek(tp, position + 1)`. - Restoring externally-managed offsets in a rebalance listener. - Reprocessing all history via `seekToBeginning`.