APP-3805: Auto-update SSH remote-server binary on version skew#9328
Merged
Conversation
Contributor
|
I'm starting a first review of this pull request. You can follow along in the session on Warp. I completed the review and posted feedback on this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR versions the SSH remote-server install path, pins installs to the client release, adds handshake version validation, and updates UI setup states for install-vs-update flows.
Concerns
- The new inline connection flow can resurrect a session after it was explicitly deregistered while
transport.connect()was still in flight. - Spontaneous remote-server disconnects no longer attempt the existing reconnect flow, so a transient proxy/server drop permanently disables remote-server-backed features for that SSH session.
- No security findings were identified in the changed lines.
Verdict
Found: 0 critical, 2 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
- Restore the contains_key guard in run_connect_and_handshake before inserting Initializing, so deregister_session winning the race against transport.connect() doesn't resurrect a torn-down session. - Restore #9289's attempt_reconnect flow on top of the new version-skew + auto-update logic. Spontaneous EOFs from a Connected session now go through the existing two-attempt reconnect path instead of being permanently terminal. - Fold the version compatibility check into run_connect_and_handshake so a stale-binary mismatch surfaces as ConnectAndHandshakeError::Initialize. This naturally avoids triggering reconnect (the session is in Initializing, not Connected, when mark_session_disconnected fires). - Make RemoteTransport object-safe again (Pin<Box<dyn Future>>) so the manager can store Arc<dyn RemoteTransport> on Connected for reconnect. Co-Authored-By: Oz <oz-agent@warp.dev>
- Fix qualified imports in ssh_transport.rs (use imported Future + parse_uname_output) - Add 5s timeout to remove_remote_server_binary call in run_connect_and_handshake - Change log::error! to log::warn! for version mismatch message - Revert transport.rs module doc comment to original wording Co-Authored-By: Oz <oz-agent@warp.dev>
- Fix error message in remove_remote_server_binary: 'Failed to remove binary: {stderr}'
- Consolidate AwaitingInstall and Updating variants into single AwaitingInstall with for_update bit
- Eliminate nested Result<Result<()>, Timeout> by using unwrap_or_else to flatten
Co-Authored-By: Oz <oz-agent@warp.dev>
alokedesai
force-pushed
the
aloke/autoupdate_remote_server
branch
from
c0a691a to
87fddcb
Compare
Co-Authored-By: Oz <oz-agent@warp.dev>
captainsafia
approved these changes
Apr 30, 2026
zerx-lab
pushed a commit
to zerx-lab/warp
that referenced
this pull request
May 3, 2026
…otdev#9328) ## Description [APP-3805](https://linear.app/warpdotdev/issue/APP-3805/client-server-version-skew) — handle client/server version skew for the SSH remote-server binary. Previously the remote binary lived at a single unversioned path. When a client updated but the remote still had an older binary, the two could silently go out of sync. This PR does three things: 1. **Version the installed path.** The binary is now written to `{dir}/{binary_name}-{version}`, so any client-server drift becomes a path miss and triggers a reinstall. The unversioned path is kept for `cargo run` / `deploy_remote_server` dev loops. 2. **Check versions on handshake.** `initialize()` now compares `server_version` against the client's release tag. On mismatch, the manager deletes the stale binary, tears the session down, and emits `SessionConnectionFailed` so the failed-banner path fires. 3. **Auto-update without a prompt.** When `check_binary()` misses but the remote already has an install directory, we skip the "Install Warp SSH tools?" modal and install directly with `is_update: true`. The shimmer reads "Updating Warp SSH Extension..." instead of "Installing...". Dev clients without a release tag fall through to the normal prompt so they don't accidentally CDN-install over a locally-deployed binary. ## Testing - `cargo test -p remote_server`, `cargo clippy -D warnings`, `cargo fmt` — all clean. - Manual against `alokedesai@136.107.29.130`: - Fresh install: modal → "Installing Warp SSH Extension..." → Ready. - Reconnect with a newer client tag: handshake mismatch detected, stale binary removed, reconnect reinstalls. - Reconnect with an older client tag while a newer versioned binary is on the remote: auto-update, no modal, "Updating..." shimmer. - Forced install failure on the update path: failed banner renders. ## Server API dependencies None — warp-server already supports `?version=` on `/download/cli` (warpdotdev#10284). --------- Co-authored-by: Oz <oz-agent@warp.dev>
1 task
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
2 participants
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.
Description
APP-3805 — handle client/server version skew for the SSH remote-server binary.
Previously the remote binary lived at a single unversioned path. When a client updated but the remote still had an older binary, the two could silently go out of sync.
This PR does three things:
{dir}/{binary_name}-{version}, so any client-server drift becomes a path miss and triggers a reinstall. The unversioned path is kept forcargo run/deploy_remote_serverdev loops.initialize()now comparesserver_versionagainst the client's release tag. On mismatch, the manager deletes the stale binary, tears the session down, and emitsSessionConnectionFailedso the failed-banner path fires.check_binary()misses but the remote already has an install directory, we skip the "Install Warp SSH tools?" modal and install directly withis_update: true. The shimmer reads "Updating Warp SSH Extension..." instead of "Installing...". Dev clients without a release tag fall through to the normal prompt so they don't accidentally CDN-install over a locally-deployed binary.Testing
cargo test -p remote_server,cargo clippy -D warnings,cargo fmt— all clean.alokedesai@136.107.29.130:Server API dependencies
None — warp-server already supports
?version=on/download/cli(#10284).