HTTP 500 on /api/videos/ Calls

I've recently noticed some issues with the /api/videos endpoint. There have been two times in the past few weeks (including tonight) when I've encountered stretches in the evening where all requests for videos come back with a status code of 500. The issue doesn't seem especially frequent and it has always resolved itself by the next day, but since I had a chance to do a little investigation tonight I wanted to report my findings in the event that they prove useful:

• The issue doesn't appear to affect the rest of the API, nor does it seem related to my API key. I've tested several other endpoints (chats, objects, games, characters, promos, and people) and they all seem to be functioning normally.
• Requests with additional parameters (format, limit, offset, filter, etc) still come back as 500, but omitting all parameters does produce the expected HTTP 200 / "Invalid API Key" error.
• I can't recall the date I last saw the issue, but I do know that it's been going on tonight since at least 9:30pm CDT.

I know that's not exactly an exhaustive report, so if there's any other information I can provide, please let me know.

Some time this afternoon I stopped receiving 500 and started seeing results again. The only trouble is that the default sort order appears to have changed. Yesterday http://www.giantbomb.com/api/videos/?api_key=<key>&limit=10 would return the 10 videos with the highest publish_date. Now that query is giving the 10 videos with the lowest id sorted in descending order by publish_date. Explicitly setting a sort order (like "sort=publish_date:desc") works as expected, but I was wondering if there was any chance the original behavior might be restored?

Relying on default behavior was perhaps a poor choice on my part, so if that's not an option I would understand, but Apple's review process means that, even if I were to get a new build submitted today, it would likely be at least a week before users of the iOS version of Giant Bomb Video Buddy would be back to good.

Yep, I was using the default sort order as well and I guess the API changed.

I also noticed that for JSON, number_of_total_results is returning a string. I'm pretty sure it was returning a number before. Not a biggie to parse it, but my app was broken.

@soup_menu:

I noticed the same problem over on the bug reporting forum.

http://www.giantbomb.com/forums/bug-reporting-33/videos-api-returns-500-error-1457578/#3

I also asked if original functionality could be restored, since your app would otherwise have to be updated. I was previously using 2 queries to get an offset, because the sorting didn't work as expected, but now it looks like the sorting parameter works as one might expect, I may be able to get away with using 1 query. Doesn't help you in the Giant Bomb Video Buddy, though. :-(

I will say that the default sort order doesn't seem to be reversed, but rather the result slice that you are given is at the old-end of the full result set, which seems bizarre, so I'm guessing this is more a bug than the new intended behavior.

For example, if you run the following:

http://www.giantbomb.com/api/videos/?video_type=10&field_list=name,hd_url,publish_date&format=xml&api_key=[your_key]

The first result will be Welcome Back Tricaster Party! - Part 02, with part 1 following, all the way down to the very first ever subscriber video. So the videos are in descending order, just sliced incorrectly.

Quick follow-up for the benefit of anyone finding this thread after the fact: the original sorting behavior was restored yesterday (November 1, 2013).