Frun1na opened a new issue, #4799:
URL: https://github.com/apache/rocketmq-dashboard/issues/4799
Follow-up to the discussion in #4592 (maintainer review, "Optional, not
blocking" section), split
out as its own design issue as suggested there.
**The gap.** `RocketMQMessageProvider.queryByTopic`
(server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQMessageProvider.java:364-434)
scans each queue of a topic between the guarded offsets and abandons a queue
silently — only a
`log.warn`, no signal to the caller — on these paths:
1. pull budget exhausted (`MAX_PULL_ATTEMPTS_PER_QUEUE`, :386-390);
2. `pullResult == null` (:392-394);
3. offset stall, `nextBeginOffset` does not advance (:397-399);
4. `OFFSET_ILLEGAL` repeated beyond `MAX_CONSECUTIVE_OFFSET_ILLEGAL`
(:408-413).
The method returns a plain `List<MessageRecordVO>`, and
`MessageQueryResult.mayBeTruncated` on
this path only reflects the result-count cap (`TOPIC_QUERY_HARD_CAP`), not
per-queue abandon. So a
query where one of four queues was abandoned mid-scan is reported and
rendered as a complete,
successful result — the same operator-facing failure mode #4592 fixes for
the DLQ resend path,
just on the read path.
**Why an issue first.** Fixing it needs a per-queue completeness channel on
the topic-query
return path, which is a design change:
- Option A: extend the topic-query result to carry `resultMayBeTruncated` /
`skippedCount` (or a
per-queue `failedQueueCount`) the way `MessageService.queryMessagesPage`
and the DLQ scan do, and
surface it through the web UI and the `rmq.message.query_by_topic` tool
output
(`outputSchema` + catalog + contract test would move together per the
#4645/#4649 conventions).
- Option B: fold the abandon cases into the existing `truncated(...)` helper
on
`MessageQueryResult` so both cap-truncation and mid-scan abandon share one
signal, mirroring
`RocketMQDLQProvider.scanDeadLetters` semantics (and the #4592 discussion
about
`failedQueueCount` vs a distinct signal).
Happy to implement once the shape is agreed — happy to take either direction
the maintainers
prefer, including whichever choice #4592 lands on for `failedQueueCount`.
**Related.** #4592 (DLQ resend outcome), #4514 (Tencent empty-page
completeness), #4388 (message
tool truncation signal). Related sibling on the consumer side:
`RocketMQMetadataProvider` caps topic-consumer scans at
`TOPIC_CONSUMER_SCAN_LIMIT` and returns
the capped list without a truncation flag (TopicController list consumers
path) — same family, can
be folded into the same design discussion if preferred.
--
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]
