tju-yxq opened a new issue, #3047: URL: https://github.com/apache/rocketmq-dashboard/issues/3047
## Problem The Tencent Cloud provider pages `DescribeMessageList` with `MESSAGE_LIMIT = 100` and `MAX_PAGES = 100`, but it stops after at most 10,000 rows without reporting truncation. The loop can also stop because `TotalCount` is missing or smaller than the number of rows returned. This has two user-visible consequences: 1. A topic/time query can return exactly 10,000 rows and claim to be complete even though the query has more matches. The current list-based API has no truncation flag, and the frontend has no way to distinguish an exhausted query from a capped scan. 2. The result list is fully materialized in memory before `MessageService.queryMessagesPage` slices one small page. At 100 rows per API call and 100 calls, this is a large amount of retained response data for what is usually a 50-row page request. The Apache provider already keeps a bounded newest-message heap and communicates a possible truncation boundary through `MessageService`. The Tencent path has neither the bound nor the signal. ## Expected behavior - Enforce a bounded result budget for Tencent topic queries (for example 2,000 records, matching the Apache provider's hard cap) rather than allowing 10,000 unbounded rows. - Keep paging deterministic when Tencent returns a full page: continue until short page, until `TotalCount` is satisfied, or until the budget is reached. - Expose an explicit `resultMayBeTruncated` signal from the provider/service so the page response can tell the UI that the budget was hit. - Avoid retaining more rows than necessary and preserve the existing task-request-id continuation behavior. -- 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]
