unbridled-41 commented on PR #11042: URL: https://github.com/apache/rocketmq/pull/11042#issuecomment-5551618332
Evidence chain (audit 2026-09-05): **Before the fix** — ff8f6f74c + regression tests only (all four production loop changes stashed): ``` testGetAllTopicConfigFetchesLastEntryWhenTotalIsOneOverPageSize:1782 expected:<101> but was:<100> testGetAllSubscriptionGroupFetchesLastEntryWhenTotalIsOneOverPageSize:1825 expected:<101> but was:<100> ``` The loop breaks after page 1; the entry at index pageSize is never requested and no error is raised. **After the fix** — branch tip 55dbfd3c3, re-measured 2026-09-05: both regression tests pass (`Tests run: 1, Failures: 0` each); full class `mvn -pl client test -Dtest=MQClientAPIImplTest` = 135/135 (measured earlier the same day); `mvn -pl broker compile` OK for the two BrokerOuterAPI occurrences. Broker-side paging contract re-verified in code (the premise the client loop must match): `AdminBrokerProcessor.java:958` sets `totalTopicNum = tcManager.getTopicConfigTable().size()` and `:1795` sets `totalGroupNum = sgManager.getSubscriptionGroupTable().size()`; pages are sliced `[seq, seq + maxNum)` with no overlap (`TopicConfigManager#subTopicConfigTable`, comment "[topicSeq, topicSeq + maxTopicNum)" at line 744, and `SubscriptionGroupManager#subGroupTable` line 324). Therefore after page k the client holds k·pageSize entries and the old terminator `seq >= totalNum - 1` is already true when exactly one entry remains — i.e. for every N ≡ 1 (mod pageSize). With the fix, a fully-consumed set still terminates on the completing page and a subsequent empty page still terminates (seq >= totalNum remains true), so no extra request is issued outside the boundary case. -- 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]
