[Bug] Incorrect end timestamp recovery in tiered index files

[majialoong]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

All

RocketMQ version

develop

JDK Version

All

Describe the Bug

IndexStoreFile reads endTimestamp from INDEX_BEGIN_TIME_STAMP instead of INDEX_END_TIME_STAMP during recovery.

Steps to Reproduce

Write an index whose timestamp is later than the file’s begin timestamp, then close and reopen the file.

What Did You Expect to See?

The reopened file should retain the persisted end timestamp.

What Did You See Instead?

The end timestamp becomes the begin timestamp, which can cause valid query results to be skipped.

Additional Context

No response

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase.

Root Cause: In IndexStoreFile.java line 117, the recovery constructor reads endTimestamp from INDEX_BEGIN_TIME_STAMP (offset 4) instead of INDEX_END_TIME_STAMP (offset 12). The write path (lines 192-193) correctly stores endTimestamp at INDEX_END_TIME_STAMP, so the recovery read is inconsistent with the write.

Impact: After reopening a tiered index file, endTimestamp equals beginTimestamp, causing valid query results within the time range to be skipped during index lookups.

Severity: Medium — data query correctness issue in the tiered store index layer.

Fix: PR #10657 addresses this with a one-line fix and includes a regression test.

---

Automated evaluation by RockteMQ-AI