# Retry-After devuelve 0 segundos

**URL:** https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550
**Category:** Bug
**Created:** [15 Octubre, 2018 14:35 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550 "2018-10-15T14:35:37Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![jdevost](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jdevost/32/119493_2.png) [@jdevost](https://meta.discourse.org/u/jdevost)
#### Post date: [15 Octubre, 2018 14:35 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550/1 "2018-10-15T14:35:37Z")

</div>

When we retry after a 429, we get another 429.

I suspect a round-down issue.

In our scenario:

- we do requests, and eventually get a `429 Too Many Request` with `Retry-After: 19`
- we wait 19 seconds, then try again:  
—\> We get a `429` again, with `Retry-After: 0 `

Now, can it be the actual values were 19.4 and 0.4 for example and they were rounded down for the Retry-After in the headers?

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [15 Octubre, 2018 18:49 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550/2 "2018-10-15T18:49:32Z")

</div>

Probably, should be an easy fix. Another starter task @erlend_sh?

---

<div class="post-metadata">

### Author: ![dinomite](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/dinomite/32/125526_2.png) [@dinomite](https://meta.discourse.org/u/dinomite)
#### Post date: [28 Noviembre, 2018 16:10 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550/3 "2018-11-28T16:10:50Z")

</div>

I’m not entirely sure where this is happening, but I suspect it has to do with use of Lua’s `tonumber()` in [rate\_limiter.rb](https://github.com/dinomite/discourse/blob/aad7df2a1ba083983aaebd186e30e369a73744bb/lib/rate_limiter.rb#L62)—quoth [Redis’ EVAL documentation](https://redis.io/commands/eval):

> Lua has a single numerical type, Lua numbers. There is no distinction between integers and floats. So we always convert Lua numbers into integer replies, removing the decimal part of the number if any.

---

<div class="post-metadata">

### Author: ![andrei](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/andrei/32/205142_2.png) [@andrei](https://meta.discourse.org/u/andrei)
#### Post date: [11 Enero, 2021 17:02 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550/4 "2021-01-11T17:02:52Z")

</div>

Me estoy encargando de este error y enviaré una solicitud de extracción mañana.

---

<div class="post-metadata">

### Author: ![andrei](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/andrei/32/205142_2.png) [@andrei](https://meta.discourse.org/u/andrei)
#### Post date: [12 Enero, 2021 16:52 UTC](https://meta.discourse.org/t/retry-after-returns-with-0-seconds/99550/5 "2021-01-12T16:52:18Z")

</div>

Resultó que no era un problema de redondeo en el script de Lua. El script de Lua ya recibe valores redondeados.

Además, no se trata en absoluto de un problema de redondeo. Podrían utilizarse segundos sin redondear, y aun así sería posible recibir una respuesta 429 con `Retry-After: 0`.

Aquí está la corrección para el problema principal:

> <https://github.com/discourse/discourse/pull/11691>
>
> If the sliding window size is N seconds, then a moment at the Nth second should …be considered as the moment outside of the sliding window.
> 
> Otherwise, if the sliding window is already full, at the Nth second, a new call wouldn't be allowed, but a time to wait before the next call would be equal to zero, which is confusing.
> 
> In other words, the end of the time range shouldn't be included in the sliding window. Let's say we start at the second 0, and the sliding window size is 10 seconds. In the current version of Rate Limiter, this sliding window will be considered as a time range \`\[0, 10\]\` (including the end of the range), which actually is 11 seconds in length.
> 
> After this fix, the time range will be considered as \`\[0, 10)\` (excluding the end of the range), which is exactly 10 seconds in length.

Y aquí está la corrección para un problema adicional que ocasionalmente puede causar el mismo error:

> <https://github.com/discourse/discourse/pull/11692>
