# The only solution I have found to workaround «429 Too Many Requests» failure from rubygems.org
**URL:** https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544
**Category:** Support
**Created:** [2017 年8 月 6 日 02:15 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544 "2017-08-06T02:15:48Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@dmitry\_fedyuk](https://meta.discourse.org/u/dmitry_fedyuk)
#### Post date: [2017 年8 月 6 日 02:15 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/1 "2017-08-06T02:15:48Z")
The only solution I have found is to revert my Discourse installation to the previous version.
This does work for me on **every** container rebuild attempt:
```plaintext
params:
version: e0285bc20ec10e117743e671c45643e63eccfdbc
```
This fails for me on **every** container rebuild attempt:
```plaintext
params:
version: tests-passed
```
So I think it is definitely a Discourse bug, and if the new Discourse release exceeds the [rubygems.org](http://rubygems.org) rate limits, it is Discourse problem, not [rubygems.org](http://rubygems.org) problem.
A possible solution for Discourse could be to implement some timeouts in gems fetching to be compatible with the [rubygems.org](http://rubygems.org) rate limits:
> **[Rate Limits - RubyGems.org API - RubyGems Guides](https://guides.rubygems.org/rubygems-org-api/#rate-limits)**
>
> Details on interacting with RubyGems.org over HTTP. | Tutorials, guides, FAQs for RubyGems package management
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2017 年8 月 6 日 05:20 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/2 "2017-08-06T05:20:29Z")
No repro on my do droplet, I can rebuild just fine without hitting rubygems rate limit.
---
### Author:  [@dmitry\_fedyuk](https://meta.discourse.org/u/dmitry_fedyuk)
#### Post date: [2017 年8 月 6 日 19:03 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/3 "2017-08-06T19:03:33Z")
I think it is typical for timing issues: they depend on environment (hardware, software, internet connection speed).
Particularly, I am using not a low-end 1Gb Digital Ocean droplet, but a dedicated [Hetzner EX41-SSD](https://www.hetzner.com/dedicated-rootserver/ex41-ssd?country=us) server.
Also I have some plugins installed (the same set in the both test cases described above).
So the problem is: «_how to make my server slower?_». Interestingly, this question leads to another ugly solution: try to run a computationally intensive task in parallel with `./launcher rebuild`. It may help somebody 😂
But the true solution would be to implement timeouts in the Discourse update script or/and in the Discourse’s virtual machine.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [2017 年8 月 6 日 21:50 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/4 "2017-08-06T21:50:20Z")
> [@dmitry\_fedyuk](#):
>
> But the true solution would be to implement timeouts in the Discourse update script
That won’t help. The logic to retrieve a bunch of gems is entirely within Rubygems. We ask, “hey can you install a bunch of gems for me?” by running `bundle install`, which calls off to something inside Rubygems. _That_ then makes a whole pile of requests, too quickly, and gets a 429, which is doesn’t politely handle. We could retry that, but hammering away repeatedly at a service that’s already said “you’re going too fast” doesn’t seem like the way to win friends and influence people.
Short of reimplementing rubygems/bundler inside the Discourse update script, there’s nothing that can be done outside of rubygems to fix this problem.
Also, why did you create a new topic for this, rather than continue on [the existing topic](https://meta.discourse.org/t/update-failing-due-to-rate-limiting-by-rubygems/64636)?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2017 年8 月 6 日 22:45 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/5 "2017-08-06T22:45:29Z")
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2017 年10 月 27 日 21:32 UTC](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544/6 "2017-10-27T21:32:46Z")
Official response from the rubygems folks:
* * *
Hi Jeff!
I conferred with the bundler folks about this issue and they told me **it was a known issue with older versions of bundler. If your users update their bundler version, the issue should go away.**
The errors are actually fastly throttling individual users, which as you might expect means that those versions of bundler are sending A LOT of requests.