Schedule queue stuck?

[rkulagow]

Sorry, not a fan of a silent fail like that. If you make a request that can't be honored, then the server is going to tell you why it couldn't satisfy the request, in plain english. If I had included the error code right from the get-go, then you wouldn't have needed to create this thread. :)

(My assumption was that all clients are going to request the MD5 first, so that they know whether they should download the schedule at all if it hasn't changed, and using that would know the min / max dates)

If you want the server to send you everything it has for a stationID, then just send something like

Code: Select all

[
    {
        "stationID": "92371"     
    }
]

Without any date field at all.

[GameGod]

Okay, fair enough. I'll update my app to get the range from the MD5 endpoint for each station. To clarify, the "schedule queued" error was being returned because of the invalid date range in my request?

[rkulagow]

Yes - the schedule queued error was because of the invalid date range; I wasn't checking whether we actually had the data for the date the client submitted, I was assuming that if we didn't have the schedule it was because we didn't have the station at all.

I'll be adding similar error checking in the MD5 request routine, but that will be later tonight.

[GameGod]

To close out this thread, I updated my app use the MD5 end point to get the valid date ranges for each station and everything is working as expected again.

Thanks.

[rkulagow]

I can make the response a little easier to parse programatically if that will help, like tagging "minDate" and "maxDate" instead of using the arrow.

Code 7020 has been updated:

https://github.com/SchedulesDirect/JSON ... 201#errors

Code: Select all

{
        "stationID": "92371",
        "serverID": "20141201.web.1",
        "code": 7020,
        "response": "SCHEDULE_RANGE_EXCEEDED",
        "minDate": "2015-06-21",
        "maxDate": "2015-07-12",
        "requestedDate": "2015-07-20",
        "message": "Date requested (2015-07-20) not within 2015-06-21 -> 2015-07-12 for stationID 92371."
}