Holes In The Log

A compacted topic holds one partition. The log before the cleaner ran:

offset	key	value
0	`a`	1
1	`b`	2
2	`a`	3
3	`c`	4
4	`b`	`null`
5	`a`	5

The cleaner has now compacted the entire log. A brand new consumer calls seek(partition, 0) and reads to the end, well inside delete.retention.ms. What does it get?

Records at offsets 0 through 5 unchanged, because compaction only reclaims space once the topic exceeds its retention size and this log is far too small to trigger it

Records at offsets 3, 4 and 5: c=4, the b tombstone, and a=5. Offsets 0, 1 and 2 no longer hold records but remain valid positions, so seeking to 0, 1 or 2 all return the record at offset 3

Three records renumbered 0, 1 and 2, because the cleaner rewrites the surviving records into fresh dense segments and offsets are reassigned during the recopy

Records at offsets 3 and 5 only. The tombstone at offset 4 is an internal cleaner marker and is never handed to a client, so the consumer never learns that b was deleted