# 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年八月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:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![mpalmer](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mpalmer/32/45740_2.png) [@mpalmer](https://meta.discourse.org/u/mpalmer)\
**Post date:** [2017年八月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")

</div>

> [@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)?

---

_[View the full topic](https://meta.discourse.org/t/the-only-solution-i-have-found-to-workaround-429-too-many-requests-failure-from-rubygems-org/67544)._