pilichoumao opened a new issue, #6882: URL: https://github.com/apache/rocketmq-dashboard/issues/6882
### Problem `rocketmq-studio` at a92c23144408cdf5729707050e9ecd9b75f1bad0 can export every native alert rule into one version-1 JSON document, while `AlertRuleTransferService.validateEnvelope` accepts only 1–200 rules per import. With 201 rules, the console's own successful export cannot be restored unchanged through its import action. On Ubuntu / JDK 21, the current production transfer service exports 201 rules and then rejects that exact document with 400 before any mutation. Splitting the same snapshot into documents of 200 and 1 lets the existing importer process every rule. This was a source-level experiment with mocked rule storage and catalog, not a real database restore. The existing four tests plus four characterization/boundary cases passed. ### Proposed bounded workflow for review Keep the existing version-1 JSON format, REST APIs and 200-rule import protection. For exports of up to 200 rules, retain the single download. For larger snapshots, show an export dialog with numbered parts of at most 200 rules and let the operator download each part separately. Filenames include the captured domain and part number. Explain that each file is imported separately and that a successful part must not be imported again (imports create new rows). This avoids a new ZIP dependency or an automatic multi-request import whose partial failure/retry semantics could duplicate rules. Each existing import remains its own transaction; the complete backup is not claimed to be atomic across parts. The complete snapshot remains available for download, rather than rejecting large backups or silently truncating them. I will prepare a tested draft for design review; it should remain draft pending agreement on this user workflow. If another recovery workflow is preferred, the reproduction and bounded-file tests still provide evidence for the decision. ### Related work and validation plan Closed #3416 and #3776 test the intentional oversized-import rejection; they do not make an oversized export restorable. Open #6784 handles mock envelope validation and #6855 handles legacy duration files. This proposal does not change those contracts. Planned checks: 200/201/400/401 boundaries; every rule exactly once with order/portable fields intact; each file keeps version/domain and the <=200 bound; normal single-download compatibility; actual page selection and both part contents; zh/en text, real browser inspection, TypeScript/build/lint and ECS tests. AI assistance was used for investigation, proposal drafting and verification. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
