Repository navigation
fix(ssh): reconnecting a host after stopping its managed server no longer fails the move (#29560) - #29586
Merged
Conversation
This was referenced Oct 16, 2026
orcad_migration_repository_id_conflict after the SSH target is re-created with the same repos
#27285
Closed
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.
ELI5
If you stopped an SSH host's managed server and then connected that host again, Orca tried to move the host's projects onto the new server a second time. The server still had the projects from the first move, and it refused the second copy. Resume could never succeed. Now Orca notices that the server already has those projects and uses its copy.
What Changed
orca environment stop, then reconnect. Every Resume failed withorcad_migration_dormant_id_conflict:worktree_meta:<repo>::<path>, and the host showed "Host locked".Mechanism:
src/main/ssh/orcad-migration-repository-link.ts. Stopping a server unlinks it on this desktop but leaves its profile on the host, rows from the first move included. The conversion already links a project the server holds at the same host path, but only when the server's row has a different id. A row with the same id was left to the import, on the assumption that it was identical. That stops holding once the server has been used: a worktree's metadata changes, and the import (assertOrcadDestinationCanonicalMetadata) refuses it. Now a same-id, same-path project is linked like a different-id one, unless the server reports that this migration already committed. That case is a lost reply after the commit, and it has to resume rather than relink.Why
stopwipe the server's profile. That deletes data on the host and does nothing for profiles already left behind.Fixes #29560 (the dormant-id conflict. The leftover
ssh -Lafter quit is a separate issue, handled separately.)Visual Proof
N/A. No UI change: the existing linked-project status line is reused.
Testing
moving the host again after its server was stopped: does a first move, edits the project on the server, runs stop's local unlink, then reconnects. It fails on main with exactly the reportedorcad_migration_dormant_id_conflict:worktree_meta:desktop-repo::/root/migrepoand passes with this change. The server keeps its edited metadata, and this desktop keeps its retained copy.orcad_migration_committed_source_cannot_be_released.pnpm tc:nodeandcheck:code-quality:changedpass.linked:[{path:/tmp/upg227-remote/home/repo}]. The repo and both worktrees kept their ids, and there was nodormant_id_conflict. The first connect was refused, correctly, because old relay-era shells were still running on the host; it connected once they were ended. A second desktop (main build) was connected to the same host in both the main repro and this run, so the two runs are like-for-like.Review
Codex (
gpt-6.1-sol, high): no findings.Agent skill upstream boundary
Notes
readStatecall, so older servers are unaffected.Checklist