apache / apache/rocketmq-dashboard
[Studio][Feature] Compare Consumer Group configuration across instances
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 683
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 58
Description
## Problem
Operators promote Consumer Group configuration between staging, disaster-recovery, and production instances, but Studio only shows one instance at a time. Verifying parity currently requires exporting inventories separately and manually joining them. Runtime observations such as lag and online clients also make naive full-row comparisons noisy.
## Proposed behavior
Add a read-only comparison workflow on the Consumer Group page that:
- loads the complete paginated inventory for two selected instances;
- classifies groups as matching, drifted, source-only, or target-only;
- compares only stable settings: namespace, subscription mode, consume type, subscription data type, delivery order type, and retry maximum;
- excludes lag, delay, clients, runtime subscriptions, timestamps, and instance-specific identifiers;
- shows field-level differences and exports the filtered result as CSV.
## Acceptance criteria
1. Source and target can be swapped without retaining stale results.
2. Older responses cannot overwrite a newer comparison.
3. Search and status filters also constrain CSV export.
4. At least two instances are required.
5. Chinese and English UI text and focused regression tests are included.
## Scope
This is an observational feature. It does not copy, create, update, or delete Consumer Groups.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the Consumer Group page and trace its existing paginated inventory loading, instance selection, filtering, and CSV export entry points. Add focused regression tests for swapping instances, stale responses, filters, and the two-instance requirement; done means the comparison shows only stable-setting differences, exports filtered results, and includes Chinese and English UI text.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100