Give a better error message when crates.io requests time out #6936
Conversation
This file contains 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
crates.io is hosted on Heroku, which means we have a hard 30 second time limit on all requests. Typically this is only hit when someone is attempting to upload a crate so large that it would have been eventually rejected anyway, but it can also happen if a user is on a very slow internet connection. When this happens, the request is terminated by the platform and we have no control over the response that gets sent. This results in the user getting a very unhelpful error message from Cargo, and some generic error page HTML spat out into their terminal. We could work around this on our end by adding a 29 second timeout *somewhere else* in the stack, but we have a lot of layers that buffer requests to protect against slow client attacks, and it'd be a pretty decent amount of work. Since we eventually want to switch over to having Cargo do the S3 upload instead of us, it doesn't make sense to spend so much time on an error scenario that eventually will go away. I've tried to keep this uncoupled from crates.io as much as possible, since alternate registries might not be hosted on Heroku or have the same restricitions. But I figure "a 503 that took more than 30 seconds" is a safe bet on this being hit. If we're ok with coupling this to crates.io, I'd like to include "If your crate is less than 10MB you can email help@crates.io for assistance" in the error message. Ref rust-lang/crates.io#1709
|
r? @ehuss (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
This sounds like a big UX improvement. The code looks good to me. But I don't know this part of the code well enough to r+. I wonder how hard it would be to check if the source.url is crates.io. If it is, then we can be as specific as we want. edit: |
|
Good idea. I've made this specific to crates.io, and given the more detailed error message |
alexcrichton
approved these changes
May 14, 2019
|
@bors: r+ |
|
📌 Commit 4d93f2d has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
May 14, 2019
Give a better error message when crates.io requests time out crates.io is hosted on Heroku, which means we have a hard 30 second time limit on all requests. Typically this is only hit when someone is attempting to upload a crate so large that it would have been eventually rejected anyway, but it can also happen if a user is on a very slow internet connection. When this happens, the request is terminated by the platform and we have no control over the response that gets sent. This results in the user getting a very unhelpful error message from Cargo, and some generic error page HTML spat out into their terminal. We could work around this on our end by adding a 29 second timeout *somewhere else* in the stack, but we have a lot of layers that buffer requests to protect against slow client attacks, and it'd be a pretty decent amount of work. Since we eventually want to switch over to having Cargo do the S3 upload instead of us, it doesn't make sense to spend so much time on an error scenario that eventually will go away. I've tried to keep this uncoupled from crates.io as much as possible, since alternate registries might not be hosted on Heroku or have the same restricitions. But I figure "a 503 that took more than 30 seconds" is a safe bet on this being hit. If we're ok with coupling this to crates.io, I'd like to include "If your crate is less than 10MB you can email help@crates.io for assistance" in the error message. Ref rust-lang/crates.io#1709
|
☀️ Test successful - checks-travis, status-appveyor |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
May 16, 2019
Update cargo 17 commits in 759b6161a328db1d4863139e90875308ecd25a75..c4fcfb725b4be00c72eb9cf30c7d8b095577c280 2019-05-06 20:47:49 +0000 to 2019-05-15 19:48:47 +0000 - tests: registry: revert readonly permission after running tests. (rust-lang/cargo#6947) - Remove Candidate (rust-lang/cargo#6946) - Fix for "Running cargo update without a Cargo.lock ignores arguments" rust-lang/cargo#6872 (rust-lang/cargo#6904) - Fix a minor mistake in the changelog. (rust-lang/cargo#6944) - Give a better error message when crates.io requests time out (rust-lang/cargo#6936) - Re-enable compatibility with readonly CARGO_HOME (rust-lang/cargo#6940) - Fix version of `ignore`. (rust-lang/cargo#6938) - Stabilize offline mode. (rust-lang/cargo#6934) - zsh: Add doc options to include non-public items documentation (rust-lang/cargo#6929) - zsh: Suggest --lib option as binary template now the default (rust-lang/cargo#6926) - Migrate package include/exclude to gitignore patterns. (rust-lang/cargo#6924) - Implement the Cargo half of pipelined compilation (take 2) (rust-lang/cargo#6883) - Always include `Cargo.toml` when packaging. (rust-lang/cargo#6925) - Remove unnecessary calls to masquerade_as_nightly_cargo. (rust-lang/cargo#6923) - download: fix "Downloaded 1 crates" message (crates -> crate) (rust-lang/cargo#6920) - Changed RUST_LOG usage to CARGO_LOG to avoid confusion. (rust-lang/cargo#6918) - crate download: don't print that a crate was the largest download if it was the only download (rust-lang/cargo#6916)
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.
crates.io is hosted on Heroku, which means we have a hard 30 second time
limit on all requests. Typically this is only hit when someone is
attempting to upload a crate so large that it would have been eventually
rejected anyway, but it can also happen if a user is on a very slow
internet connection.
When this happens, the request is terminated by the platform and we have
no control over the response that gets sent. This results in the user
getting a very unhelpful error message from Cargo, and some generic
error page HTML spat out into their terminal. We could work around this
on our end by adding a 29 second timeout somewhere else in the stack,
but we have a lot of layers that buffer requests to protect against slow
client attacks, and it'd be a pretty decent amount of work. Since we
eventually want to switch over to having Cargo do the S3 upload instead
of us, it doesn't make sense to spend so much time on an error scenario
that eventually will go away.
I've tried to keep this uncoupled from crates.io as much as possible,
since alternate registries might not be hosted on Heroku or have the
same restricitions. But I figure "a 503 that took more than 30 seconds"
is a safe bet on this being hit. If we're ok with coupling this to
crates.io, I'd like to include "If your crate is less than 10MB you can
email help@crates.io for assistance" in the error message.
Ref rust-lang/crates.io#1709