"Retry-After" header is sometimes (0) when API returns rate-limit error

[dsoprea]

Endpoint(s):

• (any)

Scope(s):

• spotify.ScopeUserReadPrivate
• spotify.ScopePlaylistReadCollaborative
• spotify.ScopePlaylistReadPrivate
• spotify.ScopePlaylistModifyPrivate
• spotify.ScopePlaylistModifyPublic

Steps to reproduce:

Inconsistent. I received a bunch of non-zero values, then I started receiving zeros, then I started getting the non-zeros again. It is currently working as expected but is clearly capable of returning zero under the right circumstances.

Expected behaviour:

Retry-After should be an integer greater than zero.

Actual behaviour:

Retry-After is given but is sometimes zero when the "API rate limit exceeded" error is received.

2017/05/21 10:09:37 gnss.spotify: [DEBUG]  Searching for artist: [disciple]
HEADER: [Keep-Alive] = [timeout=600]
HEADER: [Retry-After] = [0]
HEADER: [Access-Control-Allow-Credentials] = [true]
HEADER: [Date] = [Sun, 21 May 2017 14:09:37 GMT]
HEADER: [Connection] = [keep-alive]
HEADER: [Access-Control-Allow-Origin] = [*]
HEADER: [Access-Control-Allow-Methods] = [GET, POST, OPTIONS, PUT, DELETE]
HEADER: [Access-Control-Max-Age] = [604800]
HEADER: [Access-Control-Allow-Headers] = [Accept, Authorization, Origin, Content-Type]
HEADER: [Server] = [nginx]
2017/05/21 10:09:37 main: [ERROR]  There was an error.

[dsoprea]

Happened again while I was logging a few things for something else:

2017/05/21 14:12:57 gnss.spotify: [DEBUG]  Found ID for album under artist-ID [5BtHciL0e0zOP7prIHn3pP]: [dear agony] found as [dear agony]
STATUS CODE: (429)
HEADER: [Keep-Alive] = [timeout=600]
HEADER: [Retry-After] = [0]
HEADER: [Access-Control-Allow-Origin] = [*]
HEADER: [Access-Control-Allow-Credentials] = [true]
HEADER: [Access-Control-Max-Age] = [604800]
HEADER: [Access-Control-Allow-Headers] = [Accept, Authorization, Origin, Content-Type]
HEADER: [Server] = [nginx]
HEADER: [Connection] = [keep-alive]
HEADER: [Access-Control-Allow-Methods] = [GET, POST, OPTIONS, PUT, DELETE]
HEADER: [Date] = [Sun, 21 May 2017 18:12:57 GMT]
DECODING AN ERROR
RETRY!
ERROR BODY (LEN 80):
{
  "error": {
    "status": 429,
    "message": "API rate limit exceeded"
  }
}
ERROR DECODED: [API rate limit exceeded]
2017/05/21 14:12:57 main: [ERROR]  There was an error.
*errors.errorString we were told to retry later but no time was given

[asmitter]

Thanks for the report. Couple of questions:

1. What happens if you retry immediately when receiving a "Retry-After" of 0?
2. Are you making a lot of simultaneous requests, or are they being sent one-at-a-time?

[rolandjohann]

The number returned by that header represents the second where the subsecond amount has been truncated. So a returned 0 can mean that the duration will be of 900ms.
A proper fix will be to return milliseco da insteqd of seconds.
Temporary workaround will be to retry to succeed the request soonest or add 1 second to that duration to overcome the missing granularity.

[hughrawlinson]

Hi! This issue was addressed. Please let us know if you encounter it again, and I'll reopen the issue.

[dsoprea]

Thanks, Hugh. What was the solution?

[hughrawlinson]

It was a small bug on our side that's fixed now 😄