zmuxuny opened a new issue, #7316: URL: https://github.com/apache/rocketmq-dashboard/issues/7316
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version Current source inspected on October 21, 2026: `rocketmq-studio@127c47b06a268cc74224d5f34c56ec7c36ac0d55`. This is a tracking continuation, not a claim of a new live deployment or fresh runtime test. ### Runtime Environment Linux, Bash, tar and Python 3. The existing regression fixture executes the real packaging/upload functions and tar operations with SSH/SCP/Docker boundaries replaced. No live host, broker or deployment is changed. ### Connected RocketMQ Cluster Not required. The failure occurs during deployment-source replacement. ### Build Toolchain Bash, tar and Python 3; no backend compilation is needed for the offline reproduction. ### Describe the Bug This continues #6623, which github-actions[bot] [automatically closed after seven days without issue activity](https://github.com/apache/rocketmq-dashboard/issues/6623#issuecomment-6305426370) on October 21. That closure was inactivity housekeeping, not a maintainer rejection. Existing implementation PR #6648 remains open and Ready for review. No duplicate implementation PR is proposed. The scope is now only saved-environment recovery. The obsolete `rmqctl` cleanup portion of the original report was fixed upstream by #6676 and is not being reopened here. In the [current upload_source implementation](https://github.com/apache/rocketmq-dashboard/blob/127c47b06a268cc74224d5f34c56ec7c36ac0d55/deploy/deploy.sh#L78-L94): - If extraction fails after `deploy/` was removed, the saved `deploy/.env` cannot be moved back because its destination directory no longer exists. - The exit code is captured before the restore operation. If extraction succeeds but restoration fails, the earlier zero status is returned and deployment continues without the preserved environment. ### Steps to Reproduce Use the offline fixture in #6648 against the uncorrected upload function: 1. Seed a remote source tree with a synthetic `deploy/.env`. 2. Inject a tar extraction failure after source cleanup, then check whether the saved environment is restored before returning the extraction error. 3. Independently allow extraction to succeed but make the final restoration fail with status 73. 4. Check that upload aborts with a nonzero status and leaves the backup available instead of reporting success. These reproduce the previously documented cases. Today's recheck was source inspection, not a new execution of the fixture. ### What Did You Expect to See? Recreate the environment destination when necessary; restore the saved environment even after extraction failure; retain the first failure status; propagate a restoration failure when no earlier operation failed. Preserve the backup if restoration cannot complete. ### What Did You See Instead? The current implementation can leave the saved environment unrestored and can mask a restoration error with an earlier successful extraction status. ### Additional Context The [maintainer review](https://github.com/apache/rocketmq-dashboard/pull/6648#pullrequestreview-5531450682) accepted the minimal deployment correctness scope and requested removal of workflow edits and duplicate `rmqctl` cleanup. The current PR has addressed those requests and contains only environment recovery plus offline tests. PR head: `3a2e5e9db780f1375079ce4162470cdf29c18ec4`. - Historical local validation on October 15: all eight offline tests, `bash -n`, and `git diff --check` passed. - [CI run 38733428330](https://github.com/apache/rocketmq-dashboard/actions/runs/38733428330) for that exact head remains successful, with all five jobs passed, rechecked on October 21. - No fresh local full-suite, live deployment, or new maintainer approval is claimed. The original report and review history remain linked above. AI assistance was used for this source/status recheck and tracking continuation. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
