Wang1rrr opened a new issue, #5141:
URL: https://github.com/apache/rocketmq-dashboard/issues/5141
# [Bug] Stored message query results turn unknown queue IDs and offsets into
zero
## Affected version
`rocketmq-studio` at `4ee173ad71ae777f01111394a88358958b9abad6`.
## Problem
Message query history changes the meaning of nullable queue metadata while
saving a result snapshot. A cloud message whose queue ID and queue offset are
unknown is returned by the live query with `queueId: null` and `queueOffset:
null`, but its saved history result reports `queueId: 0` and `queueOffset: 0`.
Zero is a real queue ID and a real queue offset. It must remain
distinguishable from information the provider did not supply.
## Code evidence and reproduction
1. `MessageRecordVO.queueId` is `Integer`, and `queueOffset` is `Long`. The
frontend `MessageRecord` contract also declares both fields as `number | null`.
2. `AliyunConverters.toMessageRecord(...)` and the Tencent `toRecordVO(...)`
conversions do not populate these fields; their records therefore legitimately
contain null values.
3. `MessageService.recordMessageQuery(...)` passes the provider results
through `QueryHistoryService.buildResultSnapshot(...)`.
4. That method currently writes `r.getQueueId() == null ? 0 :
r.getQueueId()` and `r.getQueueOffset() == null ? 0L : r.getQueueOffset()` into
the snapshot.
5. `GET /api/query-history/messages/{id}/results` deserializes that snapshot
back into `MessageRecordVO`, exposing fabricated zero values.
A small unit reproduction is to build a `MessageRecordVO` with a message
ID/topic and null queue fields, pass it to `buildResultSnapshot`, and
deserialize the generated JSON. The two null fields become zero. An equivalent
round trip with actual zero values must continue to preserve zero.
## Expected behavior
Preserve unknown queue IDs and offsets as null through snapshot creation and
retrieval. Preserve actual zero and nonzero values unchanged. Continue
excluding message bodies and user properties from stored snapshots, and retain
the authenticated-operator ownership filter on history retrieval.
## Proposed scope
Keep the existing API and database schema. Remove the null-to-zero coercion
in the snapshot projection and add focused round-trip regression tests for
unknown, zero, and populated queue metadata. Existing snapshots remain
readable; previously coerced zero values cannot be repaired reliably because
they are indistinguishable from real zero values.
## Validation plan
- `QueryHistoryServiceTest`: round-trip nullable queue metadata, real zero,
nonzero offsets, body/property exclusion, and legacy snapshots with missing
optional fields.
- Existing `QueryHistoryControllerTest` and
`QueryHistoryServiceIntegrationTest`: preserve the response wrapper and
operator ownership boundaries.
- Run the relevant Maven tests on JDK 21 / Maven 3.9+, followed by the
repository's feasible backend checks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
