zed-industries/zed · error
Timed out resyncing remote client
Error message
Timed out resyncing remote client
What it means
After a connection is re-established, the client resyncs: it flushes every buffered outgoing envelope and awaits the remote's acknowledgment. The resync future is raced against an executor timer via smol::future::or (crates/remote/src/remote_client.rs:1919); if the timer fires first, the resync fails with this timeout.
Source
Thrown at crates/remote/src/remote_client.rs:1940
let response =
self.request_dynamic(payload.into_envelope(0, None, None), T::NAME, use_buffer);
async move {
let response = response.await?;
log::debug!("remote request finish. name:{}", T::NAME);
T::Response::from_envelope(response).context("received a response of the wrong type")
}
}
async fn resync(&self, timeout: Duration) -> Result<()> {
smol::future::or(
async {
self.request_internal(proto::FlushBufferedMessages {}, false)
.await?;
for envelope in self.buffer.lock().iter() {
self.outgoing_tx
.lock()
.unbounded_send(envelope.clone())
.ok();
}
Ok(())
},
async {
self.executor.timer(timeout).await;
anyhow::bail!("Timed out resyncing remote client")
},
)
.await
}
async fn ping(&self, timeout: Duration) -> Result<()> {
smol::future::or(
async {
self.request(proto::Ping {}).await?;
Ok(())
},View on GitHub (pinned to 5a9b9558db)
Solutions
- Retry the connection - reconnect flows re-attempt resync with backoff
- Check latency and bandwidth to the host; shrink in-flight state (fewer open projects/buffers) if the replayed backlog is huge
- If it consistently times out, kill the stale zed-remote-server process on the host so a fresh one starts
Defensive patterns
Strategy: retry
Try / catch
let mut backoff = Duration::from_secs(1);
loop {
match client.connect(&cx).await {
Ok(client) => break client,
Err(e) if e.to_string().contains("Timed out resyncing") => {
timer(backoff).await;
backoff = backoff.saturating_mul(2);
}
Err(e) => return Err(e),
}
} Prevention
- Size the resync timeout above the worst-case RTT of the link
- Keep the buffered-message backlog small (fewer open projects/buffers) so resync is cheap
- Repeated resync timeouts indicate link quality or a hung remote server, not a code bug
When it happens
Trigger: The resync handshake does not complete within the timeout Duration passed to resync - slow or lossy links, a remote server that accepted the connection but is hung, or a very large buffered backlog replaying slowly.
Common situations: High-latency SSH tunnels; remote host under load during server startup; Wi-Fi flapping right after reconnect.
Understand the failure class
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- Timed out pinging remote client
- origin/main tip {main_sha[:12]} unavailable locally after fe
- aborting reconnect, because not in state that allows reconne
- failed to send message: {error}
- build ids may only contain lowercase letters, numbers, '.',
AI-assisted analysis of zed-industries/zed@5a9b9558db (2026-08-20).
Data as JSON: /api/errors/7313ed6e7a259b54.
Report an issue: GitHub.