Download timeout is now intended as inactivity-timeout#3076
Merged
Conversation
cmaglie
added
type: enhancement
cmaglie
force-pushed
the
download-timeout
branch
from
cb4dbf7 to
0539441
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3076 +/- ##
==========================================
+ Coverage 69.49% 69.52% +0.03%
==========================================
Files 253 253
Lines 19172 19173 +1
==========================================
+ Hits 13323 13330 +7
+ Misses 4617 4614 -3
+ Partials 1232 1229 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This will help to make the next commits cleaner
go-downloader is able to add extra headers, there is no need to use the the round-tripper trick. Anyway, we still have API calls going in the Arduino CLI, so we need to keep NewHttpClient for such usages.
Better specify that the timeout now is an "inactivity" timeout rather than a "connection" timeout.
cmaglie
force-pushed
the
download-timeout
branch
from
0539441 to
77e10d6
Compare
3 tasks
lucarin91
approved these changes
Jan 13, 2026
|
I see this PR calls this timeout "Inactivity Timeout", but it actually the behavior of proper "Connection Timeout": No data received for given period, a single byte resets the timer. |
4 tasks
per1234
added
type: imperfection
thiagoralves
pushed a commit
to Autonomy-Logic/openplc-editor
that referenced
this pull request
Apr 4, 2026
…d timeout Arduino CLI 1.3.1 enforces a 60-second hard deadline on HTTP downloads. The ESP32 board support package (~311 MiB) cannot finish downloading within that window on most connections, causing "context deadline exceeded (Client.Timeout)" errors during `core install`. v1.4.1 (PR arduino/arduino-cli#3076) changes the timeout semantics from a total request deadline to an inactivity timeout — downloads only fail if no data arrives for 60 seconds, allowing large packages to complete. Fixes platform installation timeout regression reported in v4.1.4. https://claude.ai/code/session_01DdRdfrSzLi4Sgh8e4HhkVM
9 tasks
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
4 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.
Please check if the PR fulfills these requirements
See how to contribute
before creating one)
our contributing guidelines
UPGRADING.mdhas been updated with a migration guide (for breaking changes)configuration.schema.jsonupdated if new parameters are added.What kind of change does this PR introduce?
This PR tries to solve issues with download timeouts.
What is the current behavior?
The default setting for
network.connection_timeoutis 60 seconds. Previously, this timeout was considered a global deadline, meaning that a download started at time T would be terminated if it didn't complete before T+60.While this setup would work for most users, we've seen an increase in issues from users who report that the download is abruptly terminated without any apparent reason, simply because it ran longer than expected and exceeded the 60-second timeout.
What is the new behavior?
This PR changes the meaning of the
network.connection_timeout. It is now intended as an inactivity timeout. This means that the download is terminated if the time elapsed since the last byte received exceeds the connection timeout.This change should account for a slow connection without sacrificing the original intent of the timeout.
Does this PR introduce a breaking change, and is titled accordingly?
No
Other information
Fix #3013