[Resolved] Randomly receiving 400 response on /follows

I develop a C# twitch library, and it was brought to my attention that the /follows endpoint seems to be returning relatively random/inconsistent 400 response codes.

The issue was originally discovered in a FollowerService class that pings the /follows endpoint on an interval and fires an event when new followers are discovered.

To test the user’s claim, I setup a separate application that pinged the /follows endpoint for playhearthstone at a 1 minute interval. Sometimes it 400’d on the first call, other times it’d take a few intervals, and other times it’d take 10-20 to 400.

Endpoint in testing that sporadically returned 400 response code:
https://api.twitch.tv/kraken/channels/playhearthstone/follows?limit=0&direction=desc

Has anyone else run across this issue?

Why is your limit 0?

Generally you’d want your limit to be (1…100), you would want offset=0 to start.

Right, because the function that the service relies on is also used as a general call for pulling Twitch followers where the programmer may wish to specify a limit. The service itself does not use a limit, and it is my understanding 0 defaults to 25.

Edit:
But you’re right, it shouldn’t be a parameter, it serves no purpose. Though, it also shouldn’t lead to 400’s, I would think.

If you’re getting a 400, it probably thinks you aren’t passing a client-id, check here on how you can read the web exception response.

That’s the problem though, using a timer to replicate the call exactly the same each time, I get the error randomly. Sometimes the first time, sometimes the 15th time.

Edit:
It should be noted the call works a majority of the time (more than 90% of the time).

Are you doing something like

var request = (HttpWebRequest)WebRequest.Create(url);

?

I noticed with my own code that this sometimes had an issue with the client-id header, and a re-adding the header explicitly to the request after the .Create command helped reduce these errors to only being received during twitch deployment periods where various bits are in a weird state due to caching.

[Edit] Specifically, re-adding the Client-ID header after turning the WebRequest into the HttpWebRequest

Here’s the GetTwitchFollowers() function:
TwitchLib - TwitchAPI.cs - GetTwitchFollowers()

The function calls MakeGetRequest(), which is seen here:
TwitchLib - TwitchAPI.cs - MakeGetRequest()

The client id header is added directly tot he HttpWebRequest, so I should be good there. In addition, I pass it as a GET parameter to be safe (which I believe to be still valid).

Edit: post formatting, I accidentally linked GetFollowedUsers(), not GetTwitchFollowers(), sorry about that!

Getting the same here using the Twitch.tv Ruby gem. Doesn’t seem to be any pattern. Sending the same request again seems to work sometimes. The message says “Unparsable request body”.

Here’s the frequency/dates from our Bugsnag env on this error:

Will kick it up to the team to have investigated.

Good to see it’s not just me seeing the issue.

Edit:
Removed irrelevant details.

Sounds good, thanks a lot for the prompt responses!

Nah, re-read the code and my response, you’re right, it was bad. Edited because it’s not helpful and raises confusion on the issue.

Had a bit more of a play with request debugging on. Ran same request six times. Failed on the sixth. Exact same request each time. Here’s extra debugging in hopes that it helps: https://gist.github.com/ponny/7be3bbcfb43994f9fbca527f24b906da

Also, if it helps at all, the problem was originally noticed 9 days ago. Initially I thought it was a library error, and it took me sometime to follow up on it. Here’s the original GitHub issue (has some images):
TwitchLib issue regarding /follows

@Ponny and @swiftyspiffy

The 400 seems to be caused by sending ‘Content-Type: application/json’ while having an empty body. It is being fixed.

Thanks for the update, I will update my library now so that it makes the calls “correctly”.

Thanks again.

Not getting 400’d anymore. That seems to have been the problems.

Thanks again.

Still happening for us.

What error are you getting, @Ponny?

I should clarify.

After I removed ContentType header from the call, I no longer get the error to the best of my knowledge. I don’t think Twitch’s fix has gone live yet (as Tourny said they were working on it), so I don’t think that fixed my problem.