Repository navigation
fix(desktop): a download fails only when it stalls, not when it takes longer than 30 seconds - #830
Merged
Merged
Conversation
… longer than 30 seconds deployment::get read the body with bytes(), which the blocking client bounds by its 30-second default timeout and reports as 'error decoding response body' when that runs out. Any download taking longer than 30 seconds failed however steadily it arrived: Bun's 30 MB on a connection under about 1 MB/s, the Compose and Podman downloads, and the release lookup. Present since get() was written (#392). The body is now read as a stream, where the timeout bounds each read, so a download is given up only after 30 seconds with nothing arriving. A slow-server test fails with the old code's exact message and passes now.
dustywusty
marked this pull request as ready for review
October 27, 2026 22:04
dustywusty
requested review from
MikeRyanDev,
davidmckayv,
guidovizoso,
mxmzb and
tylerslaton
as code owners
October 27, 2026 22:04
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
guidovizoso
approved these changes
Oct 27, 2026
guidovizoso
left a comment
guidovizoso
left a comment
Collaborator
There was a problem hiding this comment.
Clearly right: a slow but steady download shouldn't fail, and today's 'error decoding response body' is a bad first impression. Approving the change. Can it come out of draft? It still matters for the release download after #852.
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.
What
A download in OpenBot Desktop now fails only when it stalls for 30 seconds, not when it takes longer than 30 seconds in total.
Root cause
deployment::get(desktop/src-tauri/src/deployment.rs), present sinceget()was written in Desktop shell: the window, the engine it acquires, and the stack it raises #392. It is shared by the release download, Bun, Compose and the engine installers.reqwest::blocking::Response::bytes(). The blocking client's default 30-second timeout bounds the whole body read there, and running out is reported aserror decoding response body.The fix
The body is read as a stream (
read_to_end), where the client's timeout bounds each read. A download is abandoned only after 30 seconds with nothing arriving. The constant is namedIDLE_TIMEOUTso the meaning is explicit.Test
A new slow-server test drips the body in pieces, each gap well under the limit, for longer than the limit in total. It fails on the old code with the old message and passes now. The full desktop Rust suite passes (543 + 148).