fix: use sudoRunWithFallback for atomic-swap rollback in Upload#3
Merged
Conversation
Plain sshExec silently fails on sudo-protected /opt/… paths, leaving remoteBase absent on disk after a failed step-2 mv. The next deploy would then incorrectly take the first-deploy path. Switch the rollback mv to the sudoRunWithFallback closure (which already holds the cached credentials from the preceding forward moves). Also surface a distinct error message depending on whether the rollback itself succeeded or failed, so operators get an actionable manual recovery command when both operations fail. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
In
internal/filetransfer/upload.go, the three-step atomic swap usedsudoRunWithFallbackfor the two forwardmvoperations but fell back to plainsshExecfor the rollbackmv. On a typical VPS where/opt/…is root-owned,sshExecfails silently — the error was discarded with_ =, leavingremoteBaseabsent on disk whileremoteBase-old-<timestamp>still exists. The next deploy then incorrectly takes the first-deploy code path.Fix
_ = sshExec(…)withrollbackErr := sudoRunWithFallback(…)in the rollback path. The closure already holds cached credentials from the preceding forward moves, so no second interactive prompt is issued.sudo mvrecovery command when both operations fail."If rollback failed…"hint from the success-rollback error message.Testing
go build ./internal/filetransfer/...passes. The change is a targeted substitution within existing error-handling logic with no new code paths to cover separately.