[Bug] TopicConfig DataVersion not persisted in split registration path

[imzs]

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

.

RocketMQ version

.

JDK Version

.

Describe the Bug

In TopicConfigManager#buildSerializeWrapper, when enableSplitRegistration
is enabled, the DataVersion was advanced by directly calling getDataVersion().nextVersion().

Under RocksDB config storage, the version was only bumped in memory
and never persisted, since RocksDBTopicConfigManager overrides
updateDataVersion() to write the version into RocksDB.

We should use updateDataVersion() to advance the version through the unified,
overridable path so it is persisted correctly and carries the proper stateMachineVersion.

Steps to Reproduce

.

What Did You Expect to See?

.

What Did You See Instead?

.

Additional Context

.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase.

Root Cause: In TopicConfigManager#buildSerializeWrapper (line 650-652), when enableSplitRegistration is enabled, the DataVersion is advanced by directly calling this.getDataVersion().nextVersion(). This bypasses the overridable updateDataVersion() method.

Under RocksDB config storage, RocksDBTopicConfigManager overrides updateDataVersion() (line 199-204) to call rocksDBConfigManager.updateKvDataVersion(), which persists the version into RocksDB. By calling getDataVersion().nextVersion() directly, the version is only bumped in memory and never persisted, and the stateMachineVersion is not included.

Impact: Topic config DataVersion becomes inconsistent between memory and RocksDB storage after split registration. On broker restart, the stale persisted version may cause unnecessary full re-registration or config mismatch.

Severity: medium

Fix: Replace this.getDataVersion().nextVersion() with this.updateDataVersion() in buildSerializeWrapper to use the unified, overridable path.

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

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

This issue has been resolved by PR #10605 (merged at 2026-07-10T10:09:59Z, commit c4ce550).

The fix addresses the same root cause identified in our analysis — DataVersion not being persisted in the split registration path. No additional PR is needed.

Closing the feedback loop: our proposed spec (spec_v1.md) targeted the same code area (TopicConfigManager#buildSerializeWrapper), confirming the diagnosis was correct.

Status: Resolved upstream — no action required from our side.