Add amd64 arch mapping and install source telemetry#10534
Conversation
Three related fixes for remote-server install failures: 1. amd64 arch mapping: Add 'amd64' to the x86_64 arm in both parse_uname_output() (setup.rs) and the install script's case statement. Some hosts report 'amd64' from uname -m instead of 'x86_64'. 2. tar pre-check: Add a 'command -v tar' check in the install script before attempting any download. If tar is missing, the script exits with NO_TAR_EXIT_CODE (4) immediately, avoiding a wasted download. The new constant and placeholder substitution are wired through setup.rs. 3. gzip SCP fallback: Add a new gzip_scp_install_fallback() function in ssh_transport.rs, triggered when the install script exits with NO_TAR_EXIT_CODE. The fallback downloads the tarball locally, extracts the binary locally with tar, gzips just the binary, uploads the .gz via SCP, then runs 'gzip -d' + 'chmod +x' on the remote host. Co-Authored-By: Oz <oz-agent@warp.dev>
The gzip fallback addressed only 0.6% of errors and neither VS Code nor Zed implements it. Keep the simpler changes: amd64 arch mapping and early tar detection with a clear error message. Co-Authored-By: Oz <oz-agent@warp.dev>
The early tar check triggers SCP fallback which re-runs the script, hitting the same tar check again. Let tar fail naturally at extraction time, same as VS Code. Only 0.6% of errors. Co-Authored-By: Oz <oz-agent@warp.dev>
Track whether the binary was installed via remote download (on_server) or client-side SCP upload (on_client). Changes: - Add InstallMethod enum (OnServer, OnClient) to transport.rs - Change install_binary() return type: Result<(), Error> -> Result<InstallMethod, Error> - Thread InstallMethod through manager -> BinaryInstallComplete -> telemetry - RemoteServerInstallation event now includes install_method field Co-Authored-By: Oz <oz-agent@warp.dev>
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR maps amd64 to x86_64 in remote-server platform detection and the install script, and threads install-source information through the remote-server install telemetry event.
Concerns
- No blocking correctness or security concerns found in the changed lines.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
|
/oz-review |
|
I'm re-reviewing this pull request in response to a review request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR maps amd64 to x86_64 in remote platform detection and adds install-source telemetry through the remote-server install flow.
Concerns
- The new SCP fallback predicate skips fallback for the
NO_HTTP_CLIENT_EXIT_CODE, which is exactly the no-curl/no-wget path the SCP upload fallback is intended to recover.
Verdict
Found: 0 critical, 1 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
| // host's inability to reach the CDN. | ||
| _ => false, | ||
| fn should_skip_scp_fallback(error: &Error) -> bool { | ||
| matches!(error, Error::ScriptFailed { exit_code , .. } if *exit_code == remote_server::setup::NO_HTTP_CLIENT_EXIT_CODE) |
There was a problem hiding this comment.
NO_HTTP_CLIENT_EXIT_CODE (no curl/wget), but that is the exact failure mode the SCP upload path is meant to recover; keep skipping only unsupported platform exits so hosts without HTTP clients still fall back to SCP.
## Description **Two changes:** ### 1. Map `amd64` → `x86_64` (7 errors, 0.7%) Some remote hosts report `amd64` from `uname -m` instead of `x86_64` (FreeBSD-style, some WSL configs). Both the Rust-side `parse_uname_output()` and the install script reject this as unsupported, even though amd64 IS x86_64. **Fix:** Add `"amd64"` to the x86_64 match arm in both `parse_uname_output()` and the install script case statement. ### 2. Track install source in telemetry The `RemoteServerInstallation` telemetry event now reports *how* the binary was installed, so we can measure SCP fallback usage in production. **Changes:** - Add `InstallSource` enum (`Server`, `Client`) to `transport.rs` - Change `install_binary()` trait return type from `Result<(), Error>` to `Result<InstallSource, Error>` - Thread `InstallSource` through the manager → `BinaryInstallComplete` event → telemetry - `RemoteServerInstallation` event payload now includes `"install_source": "server"` or `"install_source": "client"` on success, `null` on failure ### Testing I used computer use to do the following: - Docker container with `uname -m` mocked to return `amd64`: OLD script exits with "unsupported arch: amd64", NEW script proceeds past arch detection CHANGELOG-IMPROVEMENT: SSH extension now supports amd64 architecture and tracks install source in telemetry --------- Co-authored-by: Oz <oz-agent@warp.dev>
## Description **Two changes:** ### 1. Map `amd64` → `x86_64` (7 errors, 0.7%) Some remote hosts report `amd64` from `uname -m` instead of `x86_64` (FreeBSD-style, some WSL configs). Both the Rust-side `parse_uname_output()` and the install script reject this as unsupported, even though amd64 IS x86_64. **Fix:** Add `"amd64"` to the x86_64 match arm in both `parse_uname_output()` and the install script case statement. ### 2. Track install source in telemetry The `RemoteServerInstallation` telemetry event now reports *how* the binary was installed, so we can measure SCP fallback usage in production. **Changes:** - Add `InstallSource` enum (`Server`, `Client`) to `transport.rs` - Change `install_binary()` trait return type from `Result<(), Error>` to `Result<InstallSource, Error>` - Thread `InstallSource` through the manager → `BinaryInstallComplete` event → telemetry - `RemoteServerInstallation` event payload now includes `"install_source": "server"` or `"install_source": "client"` on success, `null` on failure ### Testing I used computer use to do the following: - Docker container with `uname -m` mocked to return `amd64`: OLD script exits with "unsupported arch: amd64", NEW script proceeds past arch detection CHANGELOG-IMPROVEMENT: SSH extension now supports amd64 architecture and tracks install source in telemetry --------- Co-authored-by: Oz <oz-agent@warp.dev>
Description
Two changes:
1. Map
amd64→x86_64(7 errors, 0.7%)Some remote hosts report
amd64fromuname -minstead ofx86_64(FreeBSD-style, some WSL configs). Both the Rust-sideparse_uname_output()and the install script reject this as unsupported, even though amd64 IS x86_64.Fix: Add
"amd64"to the x86_64 match arm in bothparse_uname_output()and the install script case statement.2. Track install source in telemetry
The
RemoteServerInstallationtelemetry event now reports how the binary was installed, so we can measure SCP fallback usage in production.Changes:
InstallSourceenum (Server,Client) totransport.rsinstall_binary()trait return type fromResult<(), Error>toResult<InstallSource, Error>InstallSourcethrough the manager →BinaryInstallCompleteevent → telemetryRemoteServerInstallationevent payload now includes"install_source": "server"or"install_source": "client"on success,nullon failureTesting
I used computer use to do the following:
uname -mmocked to returnamd64: OLD script exits with "unsupported arch: amd64", NEW script proceeds past arch detectionCHANGELOG-IMPROVEMENT: SSH extension now supports amd64 architecture and tracks install source in telemetry