They are already fully aware of the broken state of the API, but there’s been little-to-no API upgrades since 2013. We might eventually see an improved API, but I wouldn’t count on that being anytime soon. Your best bet would be to throw out all the bad data you get.
The issue the spawned that thread was temporary – it was introduced and fixed within about eight hours. Though it is interesting that 3ventic claims it’s been going around for a long time.
If you have examples outside of that window I’d love to see them. Thanks!
It’s been around for a long time in other endpoints where the user/channel object is part of the response, /streams for example. The whole response being incorrect was new and more serious
I have a script that repeatedly calls /streams and goes through the list of streams until the viewer count falls below a certain number.
Well, the script often ends prematurely because /streams returns data with faulty viewer counts. The following is a good example of what gets returned.
I tried to recreate the problem just now and I’m beginning to think the above example isn’t quite representative of how the bug typically behaves. I configured my script to call /streams until it gets data for about 450 top streams. I ran it in terminal repeatedly with random breaks in between each execution until I found suspicious viewer counts. I’ve probably ran it about 30 times and came up with 2 instances where the viewer count for a stream shows up as 0. I’ve tried to recreate the problem again by repeatedly running the script with almost no breaks in between, and I haven’t been able to get the bug to show up. Maybe it’s my luck, but that’s what I have for now.
As an aside, I’m pretty sure you’re aware of this, but /streams very often returns objects out of order. For example, if Stream A has a higher viewer count than Stream B, it would make sense for Stream A to come before Stream B, but this is often not the case. In fact, about 10-20% of returned stream objects are out of order. Maybe the ordering thing is intentionally done for performance reasons, which I can understand.
It has to do with our multiple layers of caching. While the entire response to an API call is cached (as expected), we also cache individual components of the response (such as each stream object). So when we rebuild the /streams response, we fetch the ordered list of streams by viewer count fresh from our streams service, but then check to see each of the stream objects in that response to see if we have a cached copy pre-rendered and if so we use that instead. That cached copy can be out of date, and have higher or lower viewer numbers, causing the ordering to appear broken. I hope that explains this strange behavior!
/kraken/streams should no longer be returning user objects in place of channel objects in some rare cases. Viewer numbers may still not be 100% accurate based on caching or other factors (such as a stream resetting and everyone reconnecting).