[Bug] Repeated subscription changed logs for unchanged gRPC subscriptions

[qianye1001]

Before Creating the Bug Report

• I have confirmed this issue has not been reported before.
• I have searched the existing issues.

Runtime platform environment

RocketMQ proxy with gRPC consumers and proxy heartbeat sync enabled.

RocketMQ version

develop branch

Describe the Bug

For gRPC consumers, ClientActivity.registerConsumer() rebuilds the subscription data set from the client Settings on each registration/heartbeat path. FilterAPI.build() creates a new SubscriptionData, whose default subVersion is initialized with System.currentTimeMillis().

When the subscription topic and filter expression are unchanged, the newly built SubscriptionData still has a newer subVersion. ConsumerGroupInfo.updateSubscription() currently logs subscription changed whenever the incoming subVersion is greater than the stored one, so the broker/proxy can repeatedly log subscription changes even though the subscription content is identical.

This is especially visible on the proxy internal heartbeat sync path, where the log thread can be HeartbeatSyncer.

Steps to Reproduce

1. Start RocketMQ proxy in cluster mode.
2. Register a gRPC consumer with a stable subscription.
3. Let the client continue sending heartbeat/settings updates or let proxy heartbeat sync propagate the registration data.
4. Observe repeated subscription changed logs with identical topic/filter content but different subVersion values.

What Did You Expect to See?

The broker/proxy should only log subscription changed when the actual subscription content changes.

What Did You See Instead?

The log is printed repeatedly because only subVersion changes.

Additional Context

The repeated log is mostly noise and internal sync overhead, but it can make operational logs misleading and noisy for stable gRPC consumers.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase (develop branch).

Root Cause:
ConsumerGroupInfo.updateSubscription() compares only subVersion (a timestamp) to decide whether to log "subscription changed". Since FilterAPI.build() creates a new SubscriptionData with subVersion = System.currentTimeMillis() on every rebuild, the log fires even when the actual subscription content (topic, filter expression, tags) is identical.

The trigger path is ClientActivity.processAndClientSettings() (telemetry/settings path, updateSubscription = true), not the heartbeat path itself.

Evidence:

Claim	File	Line
registerConsumer() rebuilds subscriptions each call	proxy/.../ClientActivity.java	:122, :443
FilterAPI.build() sets subVersion = currentTimeMillis()	remoting/.../filter/FilterAPI.java	:67; SubscriptionData.java :36
updateSubscription() logs on subVersion comparison only	broker/.../ConsumerGroupInfo.java	:187-193
No content comparison before logging	broker/.../ConsumerGroupInfo.java	:187

Impact: Log noise for stable gRPC consumers. Functional behavior is not affected (updateSubscription() returns updated = false for version-only changes).

Severity: Low

Suggested Fix: In ConsumerGroupInfo.updateSubscription(), compare actual subscription content (topic, subString, expressionType, tagsSet, codeSet) before logging "subscription changed" and replacing the stored entry. Only emit the log and update when content actually differs.

An automated fix proposal can be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by github-manager-bot

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The repeated "subscription changed" logging has been verified against the current codebase.

Root Cause: In ConsumerGroupInfo#updateSubscription() (broker module), the comparison sub.getSubVersion() > old.getSubVersion() is always true for gRPC clients because each heartbeat creates a new SubscriptionData via FilterAPI.build() → new SubscriptionData() which sets subVersion = System.currentTimeMillis(). The actual subscription content (topic, expression, tags) is never compared — only the timestamp-based version.

Additionally, the subscriptionTable.put() in this branch does not set updated = true, so the method returns false even though the table was modified, creating an inconsistent state.

Impact: Excessive INFO-level logging in production environments with gRPC consumers, making it harder to identify genuine subscription changes.

Severity: Medium — affects observability and log storage, not message delivery.

An automated fix proposal will be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by RockteMQ-AI