[ISSUE #10541] Avoid refreshing gRPC subscription versions

[qianye1001]

Summary

• Reuse the existing proxy consumer subscription subVersion when gRPC Settings rebuild the same topic/filter subscription.
• Keep a newly generated subVersion when the gRPC subscription content actually changes.
• Add ClientActivityTest coverage for unchanged and changed gRPC subscriptions.

Motivation

The issue is triggered from the proxy gRPC registration/heartbeat path. ClientActivity rebuilds SubscriptionData from Settings, and FilterAPI.build() initializes subVersion from the current time. For unchanged subscriptions, that new timestamp is propagated through proxy heartbeat sync and makes downstream registration logs look like a real subscription change.

This keeps the fix scoped to the proxy path by stabilizing the generated gRPC subscription version before registration/sync.

Closes #10541

Tests

• mvn -pl proxy -am -Dtest=ClientActivityTest -DfailIfNoTests=false test

[codecov-commenter]

Codecov Report

❌ Patch coverage is 86.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.16%. Comparing base (b5bc1ff) to head (5f492fd).

Files with missing lines	Patch %	Lines
.../rocketmq/proxy/grpc/v2/client/ClientActivity.java	86.66%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #10542      +/-   ##
=============================================
- Coverage      48.26%   48.16%   -0.11%     
+ Complexity     13436    13409      -27     
=============================================
  Files           1377     1377              
  Lines         100840   100853      +13     
  Branches       13035    13037       +2     
=============================================
- Hits           48670    48572      -98     
- Misses         46223    46312      +89     
- Partials        5947     5969      +22     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[RockteMQ-AI]

Review by github-manager-bot

Summary

This PR fixes unnecessary subVersion refresh in the proxy gRPC path. When FilterAPI.build() creates SubscriptionData, it always initializes subVersion to the current timestamp. For unchanged subscriptions, this causes downstream heartbeat sync and registration logs to falsely appear as subscription changes. The fix looks up the existing ConsumerGroupInfo and reuses the old subVersion when the subscription content has not actually changed.

Findings

• [Info] ClientActivity.java:548-551 — reuseSubscriptionVersion temporarily sets subVersion to the old value for the equality comparison, then restores it if not equal. This is functionally correct but the temporary mutation pattern is slightly fragile. Consider computing equality on the relevant fields (topic, expression type, tags/set) directly instead of relying on equals() after mutating subVersion. This would make the intent clearer and avoid any risk if SubscriptionData.equals() semantics change in the future.

• [Info] ClientActivity.java:537 — getConsumerGroupInfo(ctx, consumerGroup) is called once per buildSubscriptionDataSet invocation, which is fine. Just confirming this is a lightweight lookup (map-based) and not a heavy operation. If it ever becomes expensive, the call should be hoisted further up.

• [Info] ClientActivity.java:533 — The method signature of buildSubscriptionDataSet changed from (List<SubscriptionEntry>) to (ProxyContext, String, List<SubscriptionEntry>). Since this is a protected method, any subclass overriding it will need to update accordingly. A quick search suggests no overrides in the current codebase, but worth confirming.

Positive Notes

• Clean, well-scoped fix that addresses the root cause at the proxy gRPC layer.
• Good test coverage with both "unchanged subscription" and "changed subscription" scenarios in ClientActivityTest.
• Proper null-safety in reuseSubscriptionVersion — handles null consumerGroupInfo and null oldSubscriptionData gracefully.
• The approach of comparing with the old version and only keeping the new one when content actually changed is the right strategy.

Suggestions

• Consider adding a brief Javadoc on reuseSubscriptionVersion explaining the contract (mutates subVersion to old value, restores if subscription content differs).

---

Automated review by github-manager-bot

[fuyou001]

LGTM

[RockteMQ-AI]

LGTM — CI passed, ready for merge.

---

Automated by github-manager-bot