Add mqadmin getTopicConfig command

[Metastarx]

Which Issue(s) This PR Fixes

• Fixes feat: add mqadmin getTopicConfig command #11472

Brief Description

Existing mqadmin topic commands only expose routing, queue counts, or offsets, so users cannot inspect the TopicConfig actually stored on a broker. I added a getTopicConfig subcommand that requires a topic and optionally targets one broker or an entire cluster, falling back to brokers registered in the name server when neither target is supplied. It prints queue counts, decoded permissions, filter type, system flag, order state, attributes, and static-topic mapping details, and skips brokers where the topic is absent. I also registered the command, documented its syntax in both CLI guides, and added mocked broker/name-server tests covering option validation, direct execution, clustered execution, all-broker execution, and a broker without topic configuration.

How Did You Test This Change?

mvn test -pl tools - passed (Tests run: 176, Failures: 0, Errors: 0, Skipped: 5)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Review by github-manager-bot

Summary

Adds a new getTopicConfig mqadmin subcommand that retrieves the complete TopicConfig persisted on a broker, filling the gap where existing topic commands only expose routing or queue metadata. Supports single-broker (-b), cluster (-c), or all-broker (default) targeting, with documentation in both English and Chinese.

Findings

• [Info] GetTopicConfigSubCommand.java:78 — The topic value is trimmed but not validated for emptiness. If a user passes -t " ", it becomes an empty string after trim(). Consider adding a guard:

  if (topic.isEmpty()) {
      throw new SubCommandException("Topic name must not be empty");
  }

• [Info] GetTopicConfigSubCommand.java:170 — The FIELD_FORMAT prefix %s is always passed as an empty string in printField. If no indentation is planned, the format could be simplified to "%-40s= %s%n" for clarity. Non-blocking.

• [Info] GetTopicConfigSubCommand.java:107-120 — In printClusterConfig, slave addresses are queried individually. For large clusters with many replicas, this could generate significant traffic. This matches the pattern in other mqadmin commands (e.g., TopicStatusSubCommand), so it is consistent. Just noting for awareness.

Positive Observations

• Correctness: Proper handling of TOPIC_NOT_EXIST response code — a topic may exist only on some brokers, and the command gracefully skips absent brokers instead of failing the entire query.
• Null safety: Good null checks on brokerAddr, topicConfig, clusterInfo, and brokerData.
• Option design: Using OptionGroup for -b/-c mutual exclusion is the right approach, preventing ambiguous targeting.
• Tests: Excellent coverage — option validation, single broker, cluster, all-broker enumeration, and missing topic scenarios. The use of ServerResponseMocker keeps tests hermetic and fast.
• Documentation: Both English and Chinese docs are updated, maintaining consistency with the existing command reference format.
• Static topic support: The instanceof TopicConfigAndQueueMapping check correctly surfaces mapping details when present.

Verdict

Clean implementation that follows existing mqadmin patterns well. The suggestions above are minor. LGTM from my side — leaving final approval to the maintainers.