Skip to content

[Bug] Proxy Admin QueryMessage drops the fractional second of the time window #11234

Description

@3219378872

Search before asking

I checked open and closed issues/PRs for queryMessage, ListMessage, begin_timestamp, delivery timestamp and ProxyAdminGrpcService. #10826 added this RPC. I found no existing fix for the query time window. Nearby open work (#11105, #11117, #10686, #11228, #11232) is a different path.

What happened?

ListMessageRequest.begin_timestamp and end_timestamp are google.protobuf.Timestamp values. admin.proto says the range is inclusive. ProxyAdminGrpcService.queryMessage converts each bound with only getSeconds():

long begin = request.hasBeginTimestamp()
    ? TimeUnit.SECONDS.toMillis(request.getBeginTimestamp().getSeconds()) : 0L;
long end = request.hasEndTimestamp()
    ? TimeUnit.SECONDS.toMillis(request.getEndTimestamp().getSeconds()) : Long.MAX_VALUE;

The fractional second is stored in nanos and is dropped. Timestamps.fromMillis puts that fraction in nanos, so any window that is not an exact second is shifted down by up to 999ms. The same class already keeps nanos for ResetGroupOffset.

The broker treats the resulting longs as inclusive millisecond store timestamps (IndexFile.selectPhyOffset: timeRead >= begin && timeRead <= end, and isTimeMatched skips an index file whose range misses the window). A truncated begin pulls in messages from the previous partial second. A truncated end drops messages that are still inside the requested end, and can skip an index file whose first store timestamp sits in that partial second.

Unset bounds stay 0 and Long.MAX_VALUE. This is not the unimplemented subscription / lite_topic search, and it is not page or scroll pagination.

Runtime

Ubuntu 24.04, x86_64. Reproduced with the existing ProxyAdminGrpcServiceTest mocks (route stub plus AdminService). No running broker is required: the wrong bounds are visible on the queryMessage call the proxy makes.

develop at 78b96bc5e21216cd7896efae08f90c5cde4cae53, including the pinned rocketmq-apis submodule at 3e60073c6dab3430feaec443824802e23ecda681.

Temurin 8u504-b01, Maven 3.8.7. JDK 21 cannot run this test class: the pinned Mockito/Byte Buddy rejects class-file major version 65.

Reproduction

  1. Call QueryMessage with message_key set and a begin/end built by Timestamps.fromMillis, for example begin 1700000000500 and end 1700000001250.
  2. Observe the beginTimestamp / endTimestamp passed to the broker admin query.

On the unpatched proxy the test fails:

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
Argument(s) are different! Wanted:
adminService.queryMessage(
    "127.0.0.1:10911", "topicA", "key-1", <any integer>,
    1700000000500L, 1700000001250L, false, true, <any long>);
Actual invocations have different arguments:
adminService.queryMessage(
    "127.0.0.1:10911", "topicA", "key-1", 32,
    1700000000000L, 1700000001000L, false, true, 3000L);

The RPC itself still returns OK. The window is wrong.

Expected behavior

Pass 1700000000500 and 1700000001250 through to AdminService.queryMessage. An omitted timestamp should still mean begin 0 and end Long.MAX_VALUE. ResetGroupOffset should keep its current millisecond value (seconds * 1000 + nanos / 1_000_000).

Do not change GrpcConverter. Receive-path delivery timestamps, including the TIMER_DELAY_SEC "now + delay" behavior covered by open PR #10686, stay as they are.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions