Fix: reset pos when crossing segment boundary in find_offset_in_segments

[kickster97]

WHAT is this pull request doing?

Fixes #1771

Restores the pos = 4u32 reset in find_offset_in_segments when advancing to the next segment.

In #1479, the original pos = 4_u32 was changed to rfile.pos = 4u32. During review it was mentioned that the method uses a local pos variable, not rfile.pos. When resolving, the line was removed entirely instead of being changed back to pos = 4u32.

Without the reset, when a timestamp-based x-stream-offset falls between two segments, the method walks all messages in the first segment, crosses to the next segment, and reads from the old segment's end position, causing an IndexError or potentially a SEGFAULT.

HOW can this pull request be tested?

Run added spec

[claude]

Code Review: No issues found.

The fix is correct. When find_offset_in_segments transitions to the next segment (line 108), pos must be reset to 4u32 to skip the 4-byte segment header. Without the fix, pos retained the stale offset from the previous (exhausted) segment, leading to reading garbage data or panicking on an out-of-bounds slice. The test covers the exact scenario.

[viktorerlingsson]

Oh, good catch. I've mostly tested with int offsets, and then you can never be between two segments, so that case was missed. In any other case we only ever check one segment in find_offset_in_segments, so reseting pos wasn't needed.

We should be able to eliminate that for timestamp offsets as well by using @segment_last_ts, so we don't have to scan a full segment only to move on to the next. But then we really need this as well #1760

[claude]

Code Review

No issues found.

The fix correctly resets pos to 4u32 when crossing a segment boundary in find_offset_in_segments. Without this, the old position from the previous segment would be used to index into the new segment file, reading garbage data or going out of bounds. The new spec covers this case well.