RockteMQ-AI commented on issue #4799: URL: https://github.com/apache/rocketmq-dashboard/issues/4799#issuecomment-5769329584
**Issue Evaluation** Category: `enhancement` | Status: **Evaluated** **Feasibility:** feasible **Scope:** `RocketMQMessageProvider.queryByTopic` (server message query path), `MessageQueryResult`, web UI query result display, and potentially `RocketMQMetadataProvider` topic-consumer scan path. **Compatibility:** No breaking changes — this adds a missing completeness signal to an existing return path. Thank you for the detailed analysis and the clear linkage to #4592, #4514, and #4388. The gap you identified — per-queue scan abandonment being silently swallowed while the result is reported as complete — is a real correctness concern on the read path, mirroring the write-path issue fixed in #4592. **Assessment:** - Both Option A (extend result with per-queue completeness fields) and Option B (fold into existing `truncated(...)` helper) are viable. Option B has the advantage of reusing an established signal pattern already used by the DLQ scan path, which keeps the API surface smaller. - The key design decision is whether per-queue abandon should be a distinct signal (e.g., `failedQueueCount`) or merged into the existing `resultMayBeTruncated` flag. Merging is simpler but loses diagnostic granularity; a distinct field is more informative for operators but adds API surface. - The sibling issue on `RocketMQMetadataProvider` topic-consumer scan capping is worth addressing in the same design pass to avoid divergent completeness semantics across query paths. **Recommendation:** This is a good candidate for a maintainer design decision before implementation. The author's willingness to implement either direction is appreciated — suggesting to align with whatever `failedQueueCount` shape #4592 lands on for consistency. --- *Automated evaluation by github-manager-bot* -- 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]
