[Bug] Split registration can skip topic updates after #9521

[RongtongJin]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.
• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

All platforms when broker split registration is enabled.

RocketMQ version

develop after #9521 / commit 2accb9797771b9395d427eef1d6a7982f27b8dfc.

JDK Version

Not JDK-specific.

Describe the Bug

#9521 removed the DataVersion advancement from TopicConfigManager#buildSerializeWrapper when enableSplitRegistration is enabled.

During split broker registration, BrokerController#registerBrokerAll sends topic configs in multiple RegisterBrokerBody requests. RouteInfoManager#registerBroker stores the broker DataVersion after each request and uses it to decide whether topic queue data needs to be updated. If every split request carries the same DataVersion, the later split requests can be treated as unchanged for topics that already exist under the broker, so topic config updates in those later batches may be skipped.

Steps to Reproduce

1. Enable broker split registration with enableSplitRegistration=true and configure enough topics to require multiple registration batches.
2. Let the broker register once so the name server already has route data for those topics.
3. Update topic configs for topics that are not in the first split batch.
4. Trigger broker registration again.

What Did You Expect to See?

Every split registration batch should be processed as a topic config update, so name server route data reflects updated topic configs from all batches.

What Did You See Instead?

Only batches that are considered changed by DataVersion are guaranteed to update existing topic route data. Later split batches with the same DataVersion can be skipped for existing topics.

Additional Context

Reverting #9521 restores the previous behavior where each split registration wrapper advances the topic config DataVersion, so each batch is visible as a distinct update to the name server.

[oss-sentinel-ai]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase.

Root Cause: PR #9521 removed the DataVersion.nextVersion() call from TopicConfigManager#buildSerializeWrapper when enableSplitRegistration is enabled. During split broker registration, the broker sends topic configs in multiple batches. The NameServer's RouteInfoManager uses DataVersion comparison (isBrokerTopicConfigChanged) to decide whether topic route data needs updating. After the first batch is processed and its DataVersion is stored in brokerLiveTable, subsequent batches carrying the same DataVersion are treated as unchanged — causing topic config updates in later batches to be skipped for existing topics.

Impact: NameServer route data may not reflect topic config updates for topics that fall outside the first split registration batch. This is a data consistency issue between broker and name server.

Severity: High

Affected code path:

• RouteInfoManager#registerBroker → isBrokerTopicConfigChanged (line ~352) compares DataVersion from each split batch against stored value
• isTopicConfigChanged (line ~447) relies on the same comparison, so existing topics in later batches get skipped

PR #10426 correctly restores the DataVersion advancement and adds a regression test.

---

Automated evaluation by github-manager-bot