This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
download_gem not being retried #4846
Labels
Comments
|
can you try running with The fix is likely going to be wrapping https://github.com/bundler/bundler/blob/c85b597e81fccb5be4db6c1718de4768ad653345/lib/bundler/installer/parallel_installer.rb#L92 in a |
|
@segiddins sure. I'll set my builds to doing that. Not sure how long it'll take to get a repro! |
|
@segiddins if |
|
@segiddins @indirect Here's some debug output from one of our freebsd machines. We have had a few other repros today so let @jkeiser or myself know if you need more! https://gist.github.com/scotthain/58da989cfd632f252e3d1f7c20a2919e |
|
The relevant bit: |
jkeiser
added a commit
to jkeiser/bundler
that referenced
this issue
Aug 11, 2016
Merged
jkeiser
added a commit
to jkeiser/bundler
that referenced
this issue
Aug 11, 2016
bundlerbot
added a commit
that referenced
this issue
Aug 11, 2017
Retry downloading gems consistently across all versions of RubyGems ### What was the end-user problem that led to this PR? `Gem::RemoteFetcher::FetchError` failures were not being retried when downloading gems. Retrying downloading of gems for network blips is very ideal and helpful in CI environment. ### What was your diagnosis of the problem? - The retry logic that existed (using `Bundler::Retry`) for `Bundler::RubygemsIntegration#download_gem` was not getting called, becase `Bundler.rubygems` defaulted to a sub class of `Bundler::RubygemsIntegration::MoreFuture`, which inherited from `Bundler::RubygemsIntegration::Future` and `#download_gem` in there didn't perform download with retry logic. - Sending `Gem::RemoteFetcher::FetchError` as an argument to `Bundler::Retry` meant, `Bundler::Retry` would fail first thing,[ if exception being raised was the one being supplied](https://github.com/bundler/bundler/blob/5a61b65ad5ec1df1539ecf8bc5d124f2b254ba14/lib/bundler/retry.rb#L46..L49). The intent is to retry when downloading fails. **Example of how sub classing issue looked like:** ```ruby class RubygemsIntegration def download_gem "I retry when downloading" end end class Future < RubygemsIntegration def download_gem "I don't retry when downloading" end end class MoreFuture < Future # no download_gem end mf = MoreFuture.new #=> Bundler.rubygems where RubyGem version is > 2.1.0 mf.download_gem => "I don't retry when downloading" ``` **Example of Bundler::Retry** ```ruby Bundler::Retry.new("download gem from", StandardError).attempts do puts "I will only print once, whereas I should print 4 times" raise StandardError.new("FooBar") end ``` ### What is your fix for the problem, implemented in this PR? I added the retry logic for to `Bundler::RubygemsIntegration::Future#download_gem` and removed `Gem::RemoteFetcher::FetchError` as an argument for failed exceptions. ### Why did you choose this fix out of the possible options? I chose this fix because this fix fulfills the expected behavior(#4846). Also added specs that makes sure retry logic is intact, which otherwise would have failed without the current logic in place.
segiddins
pushed a commit
that referenced
this issue
Aug 19, 2017
Retry downloading gems consistently across all versions of RubyGems ### What was the end-user problem that led to this PR? `Gem::RemoteFetcher::FetchError` failures were not being retried when downloading gems. Retrying downloading of gems for network blips is very ideal and helpful in CI environment. ### What was your diagnosis of the problem? - The retry logic that existed (using `Bundler::Retry`) for `Bundler::RubygemsIntegration#download_gem` was not getting called, becase `Bundler.rubygems` defaulted to a sub class of `Bundler::RubygemsIntegration::MoreFuture`, which inherited from `Bundler::RubygemsIntegration::Future` and `#download_gem` in there didn't perform download with retry logic. - Sending `Gem::RemoteFetcher::FetchError` as an argument to `Bundler::Retry` meant, `Bundler::Retry` would fail first thing,[ if exception being raised was the one being supplied](https://github.com/bundler/bundler/blob/5a61b65ad5ec1df1539ecf8bc5d124f2b254ba14/lib/bundler/retry.rb#L46..L49). The intent is to retry when downloading fails. **Example of how sub classing issue looked like:** ```ruby class RubygemsIntegration def download_gem "I retry when downloading" end end class Future < RubygemsIntegration def download_gem "I don't retry when downloading" end end class MoreFuture < Future # no download_gem end mf = MoreFuture.new #=> Bundler.rubygems where RubyGem version is > 2.1.0 mf.download_gem => "I don't retry when downloading" ``` **Example of Bundler::Retry** ```ruby Bundler::Retry.new("download gem from", StandardError).attempts do puts "I will only print once, whereas I should print 4 times" raise StandardError.new("FooBar") end ``` ### What is your fix for the problem, implemented in this PR? I added the retry logic for to `Bundler::RubygemsIntegration::Future#download_gem` and removed `Gem::RemoteFetcher::FetchError` as an argument for failed exceptions. ### Why did you choose this fix out of the possible options? I chose this fix because this fix fulfills the expected behavior(#4846). Also added specs that makes sure retry logic is intact, which otherwise would have failed without the current logic in place. (cherry picked from commit c14d59a)
segiddins
pushed a commit
that referenced
this issue
Aug 19, 2017
Retry downloading gems consistently across all versions of RubyGems ### What was the end-user problem that led to this PR? `Gem::RemoteFetcher::FetchError` failures were not being retried when downloading gems. Retrying downloading of gems for network blips is very ideal and helpful in CI environment. ### What was your diagnosis of the problem? - The retry logic that existed (using `Bundler::Retry`) for `Bundler::RubygemsIntegration#download_gem` was not getting called, becase `Bundler.rubygems` defaulted to a sub class of `Bundler::RubygemsIntegration::MoreFuture`, which inherited from `Bundler::RubygemsIntegration::Future` and `#download_gem` in there didn't perform download with retry logic. - Sending `Gem::RemoteFetcher::FetchError` as an argument to `Bundler::Retry` meant, `Bundler::Retry` would fail first thing,[ if exception being raised was the one being supplied](https://github.com/bundler/bundler/blob/5a61b65ad5ec1df1539ecf8bc5d124f2b254ba14/lib/bundler/retry.rb#L46..L49). The intent is to retry when downloading fails. **Example of how sub classing issue looked like:** ```ruby class RubygemsIntegration def download_gem "I retry when downloading" end end class Future < RubygemsIntegration def download_gem "I don't retry when downloading" end end class MoreFuture < Future # no download_gem end mf = MoreFuture.new #=> Bundler.rubygems where RubyGem version is > 2.1.0 mf.download_gem => "I don't retry when downloading" ``` **Example of Bundler::Retry** ```ruby Bundler::Retry.new("download gem from", StandardError).attempts do puts "I will only print once, whereas I should print 4 times" raise StandardError.new("FooBar") end ``` ### What is your fix for the problem, implemented in this PR? I added the retry logic for to `Bundler::RubygemsIntegration::Future#download_gem` and removed `Gem::RemoteFetcher::FetchError` as an argument for failed exceptions. ### Why did you choose this fix out of the possible options? I chose this fix because this fix fulfills the expected behavior(#4846). Also added specs that makes sure retry logic is intact, which otherwise would have failed without the current logic in place. (cherry picked from commit c14d59a)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It appears that retry applies to fetching specs and talking to git, but not to actually retrieving the gems themselves. We have received this error multiple times in the past month, even with
bundle install ... --retry 5:Gem::RemoteFetcher::FetchError: Errno::ECONNRESET: Connection reset by peer - SSL_connectBundler 1.12.5, Rubygems 2.6.5, Ruby 2.1.8p440.
For one example:
I can't find the code that's supposed to retry ECONNRESET (or indeed any rubygems request): rubygems'
Gem::RemoteFetcherdoesn't seem to take a parameter for retries, nor is bundler passing one.: https://github.com/bundler/bundler/blob/28ded71b5c399fde3ecbbe785f6077312f2c54c7/lib/bundler/rubygems_integration.rb#L277-L281Since it happens intermittently, it's a little hard to repro, but we do enough builds to find it often. #4729 seems to have hit it as well.
The text was updated successfully, but these errors were encountered: