# Objective
- Stop language-server update checks from waiting forever.
**Note:** I tried to find any existing issue but no luck.
## Solution
- Set one time limit for the full response body. If the GitHub, for
example, release request stops responding, return an error. Do not let
it block language-server update checks without limit.
## Testing
- Did you test these changes? If so, how?
1. This is a flaky issue, reproducing it is not that trivial.
2. The easiest way I found is just restarting Zed until you get the
notification in the status bar `Checking for updates
<language_server_naem>`
- Are there any parts that need more testing?
No
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
See above.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
- macOS
- Linux
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<img width="2624" height="2260" alt="CleanShot 2026-08-03 at 20 29
11@2x"
src="https://github.com/user-attachments/assets/83e2781c-15bc-4924-be33-88c26f20387d"
/>
---
Release Notes:
- Fixed language servers update checks
Long-lived streaming responses (LLM completions) can stall when the
socket goes silent but the connection is never closed, leaving a read
that never returns to hang the request indefinitely. Add an opt-in
read_timeout parameter.
Release Notes:
- N/A
StreamReader::poll_next dropped the reader it take()s whenever the read
returned Poll::Pending, so the next poll reported end-of-stream. And
poll_read_buf measured bytes via ReadBuf::filled(), which never advances
when the reader writes through initialize_unfilled(), so every read
counted as zero bytes. Together these made any AsyncBody::from_reader
request body (e.g. one backed by async_fs::File, which returns Pending
on its first read) upload as an empty or truncated body.
Keep the reader across Pending polls and use the byte count that
futures::AsyncRead::poll_read returns.
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Co-authored-by: Marshall <marshall@zed.dev>
This reverts commit 2882636c06.
This was causing Zed to crash immediately on startup with the following
error:
```
thread 'main' (74835290) panicked at /Users/maxdeviant/.cargo/git/checkouts/reqwest-dc13ba947e7b959e/c156624/src/async_impl/body.rs:365:33:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
```
Closes FR-118.
Release Notes:
- Reverted https://github.com/zed-industries/zed/pull/60301
When Zed was downloading an update and the machine went to sleep, the
download would hang indefinitely on wake because the in-flight TCP
connection had silently died and nothing ever timed it out or retried.
This adds an inactivity `read_timeout` to the HTTP client so a stalled
response body errors out instead of hanging forever
(slow-but-progressing downloads are unaffected, since the timeout resets
on each chunk). It also promotes `App::on_system_wake` to a
multi-subscriber `Subscription` API and uses it in the auto-updater to
cancel an interrupted check/download on wake and start a fresh attempt.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fix hanging Zed update downloads after system sleep
## Summary
Tune the shared `ReqwestClient` builder so HTTP connections that have
silently gone bad on a flaky network path are detected and dropped
rather than reused.
A stale, reused HTTP/2 connection (after a NAT/conntrack timeout, a
silent reset, or a degraded path) is a common source of intermittent
TLS `BadRecordMac` errors against long-lived endpoints such as
`cloud.zed.dev`. The client already retries these (`HttpSend` is
retryable with exponential backoff), but users still see periodic
multi-second stalls and "connection error" warnings.
These settings make the client probe and recycle connections instead of
sending a request's first records into a connection that is already
dead:
- `tcp_keepalive(30s)` — surface dead TCP connections instead of reusing
them.
- `pool_idle_timeout(30s)` — bound how long an idle connection lingers
in the pool.
- `http2_keep_alive_interval(15s)` / `http2_keep_alive_timeout(10s)` /
`http2_keep_alive_while_idle(true)` — ping idle HTTP/2 connections so
broken ones are torn down.
All three constructors (`new`, `user_agent`, `proxy_and_user_agent`) go
through `builder()`, so every Zed HTTP client picks this up.
## Notes
- Values are conservative; they can be tightened if stale-connection
errors persist.
- `tcp_keepalive_interval` is not yet available in the pinned
`zed-reqwest`
fork rev, so only the initial keepalive idle time is set here.
## Verification
Behavior is network-dependent, so there is no deterministic test.
Verified
that the crate builds (`cargo check -p reqwest_client`). The change is
being validated empirically against a setup that reproduces the
`BadRecordMac` errors.
Release Notes:
- Improved resilience to intermittent network errors by detecting and
dropping stale HTTP connections instead of reusing them.
Closes https://github.com/zed-industries/zed/issues/15968
Release Notes:
- Added the ability to use Ollama as an edit prediction provider
---------
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>
This was pulling in tokio which is pretty unfortunate. The solution is
to do the `reqwest::Form` to `http::Reqwest` conversion in the
reliability crate instead of our http client wrapper.
Release Notes:
- N/A
Closes #ISSUE
Remove unused method `HttpClient::type_name`. Looking at the PR from a
year ago when it was added, it was never actually used for anything and
seems like a prototyping artifact.
Other misc changes for the `http_client` crate include:
- Use `derive_more::Deref` for `HttpClientWithUrl` (already used for
`HttpClientWithProxy`)
- Move `http_client::proxy()` higher up in the trait definition. (It was
in between methods that have default implementations)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
- [x] Handle uploading minidumps from the remote_server
- [x] Associate minidumps with panics with some sort of ID (we don't use
session_id on the remote)
- [x] Update the protobufs and client/server code to request panics
- [x] Upload minidumps with no corresponding panic
- [x] Fill in panic info when there _is_ a corresponding panic
- [x] Use an env var for the sentry endpoint instead of hardcoding it
Release Notes:
- Zed now generates minidumps for crash reporting
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR makes it so we send the `User-Agent` header on the WebSocket
connection requests when connecting to Collab.
We use the user agent set on the parent HTTP client.
Release Notes:
- N/A
Closes#22991
Release Notes:
- Added support for respecting the NO_PROXY environment variable when
any HTTP proxy is configured. For the exact NO_PROXY env var strings
that are supported, see [NoProxy in the reqwest
docs](https://docs.rs/reqwest/latest/reqwest/struct.NoProxy.html#method.from_env).
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Closes#27641
This PR fixes invalid proxy URIs being registered despite the URI not
being a valid proxy URI.
Whilst investigating #27641 , I noticed that currently any proxy URI
passed to `RequestClient::proxy_and_user_agent` will be assigned to the
created client, even if the URI is not a valid proxy URI. Given a test
as an example:
We create an URI here and pass it as a proxy to
`ReqwestClient::proxy_and_user_agent`:
https://github.com/zed-industries/zed/blob/main/crates/reqwest_client/src/reqwest_client.rs#L272-L273
In `ReqwestClient::proxy_and_user_agent`we take the proxy parameter here
9b40770e9f/crates/reqwest_client/src/reqwest_client.rs (L46)
and set it unconditionally here:
9b40770e9f/crates/reqwest_client/src/reqwest_client.rs (L62)
, not considering at all whether the proxy was successfully created
above. Concluding, we currently do not actually check whether a proxy
was successfully created, but rather whether an URI is equal to itself,
which trivially holds. The existing test for a malformed proxy URI
9b40770e9f/crates/reqwest_client/src/reqwest_client.rs (L293-L297)
does not check whether invalid proxies cause an error, but rather checks
whether `http::Uri::from_static` panics on an invalid URI, [which it
does as
documented](https://docs.rs/http/latest/http/uri/struct.Uri.html#panics).
Thus, the tests currently do not really check anything proxy-related and
invalid proxies are assigned as valid proxies.
---
This PR fixes the behaviour by considering whether the proxy was
actually properly parsed and only assigning it if that is the case.
Furthermore, it improves logging in case of errors so issues like the
linked one are easier to debug (for the linked issue, the log will now
include that the proxy schema is not supported in the logs).
Lastly, it also updates the test for a malformed proxy URI. The test now
actually checks that malformed proxy URIs are not registered for the
client rather than testing the `http` crate.
The update also initially caused the [test for a `socks4a`
proxy](9b40770e9f/crates/reqwest_client/src/reqwest_client.rs (L280C1-L282C50))
to fail. This happened because the reqwest-library introduced supports
for `socks4a` proxies in [version
0.12.13](https://github.com/seanmonstar/reqwest/blob/master/CHANGELOG.md#v01213).
Thus, this PR includes a bump of the reqwest library to add proper
support for socks4a proxies.
Release Notes:
- Added support for socks4a proxies.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
http-client pulled in rustls which in turn meant that gpui depended on
rustls/aws-lc-sys. This commit extracts http-client-tls crate to
separate the http-client and tls dependencies.
Closes #ISSUE
Release Notes:
- N/A
closes https://github.com/zed-industries/zed/issues/19620.
I am not 100% sure on how to test this though. @elithrar: would you mind
giving this branch a shot and seeing if it works for you? I kicked off
bundling for this pull request and you should be able to download a DMG
from the CI artifacts as soon as it's done building.
Release Notes:
- Fixed a bug that caused OS-level CA certificate bundles to not be
respected.
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This removes the `low_speed_timeout` setting from all providers as a
response to issue #19509.
Reason being that the original `low_speed_timeout` was only as part of
#9913 because users wanted to _get rid of timeouts_. They wanted to bump
the default timeout from 5sec to a lot more.
Then, in the meantime, the meaning of `low_speed_timeout` changed in
#19055 and was changed to a normal `timeout`, which is a different thing
and breaks slower LLMs that don't reply with a complete response in the
configured timeout.
So we figured: let's remove the whole thing and replace it with a
default _connect_ timeout to make sure that we can connect to a server
in 10s, but then give the server as long as it wants to complete its
response.
Closes#19509
Release Notes:
- Removed the `low_speed_timeout` setting from LLM provider settings,
since it was only used to _increase_ the timeout to give LLMs more time,
but since we don't have any other use for it, we simply remove the
setting to give LLMs as long as they need.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Peter Tripp <peter@zed.dev>
Closes#19362
This pull request includes several updates to the `reqwest_client` crate
and its dependencies. The most important changes involve adding support
for SOCKS proxies, improving error handling for proxy URIs, and adding
tests for proxy functionality.
### Dependency Updates:
*
[`Cargo.toml`](diffhunk://#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542L394-R401):
Added support for SOCKS proxies in the `reqwest` dependency by including
the `socks` feature.
### Code Improvements:
*
[`crates/reqwest_client/src/reqwest_client.rs`](diffhunk://#diff-8e036b034e987390be2f57373864b75d6983f0cf84e85c43793eb431d13538f3L47-R52):
Improved error handling when parsing proxy URIs by logging errors
instead of directly panicking.
### Testing Enhancements:
*
[`crates/reqwest_client/src/reqwest_client.rs`](diffhunk://#diff-8e036b034e987390be2f57373864b75d6983f0cf84e85c43793eb431d13538f3R274-R317):
Added tests to verify the handling of various proxy URIs, including
valid and invalid cases.
Release Notes:
- N/A
Closes#19131Closes#19039
fixes the broken auto-updater.
I had the bright idea of using streams as the most common unit of data
transfer. Unfortunately, streams are not re-usable. So HTTP redirects
that have a stream body (like our remote server and auto update
downloads), don't redirect, as they can't reuse the stream. This PR
fixes the problem and simplifies the AsyncBody implementation now that
we're not using Isahc.
Release Notes:
- N/A
REplace isahc with ureq everywhere gpui is used.
This should allow us to make http requests without libssl; and avoid a
long-tail of panics caused by ishac.
Release Notes:
- (potentially breaking change) updated our http client
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
