No service causes an error

[werebus]

We have some code to handle when there are no remaining departures for a stop, which works as far as I know. However, it appears to be the case that when there is no service (as opposed to no service remaining), InfoPoint returns an empty array ([]) instead of an empty collection of RouteDirections and we get:

Uncaught TypeError: Cannot read property 'RouteDirections' of undefined`

This is pretty much an error on the InfoPoint end of things; what we're getting back from the API isn't in the spec. If I were to guess what the endpoint should return, it would be this:

[
  {"RouteDirections":[],
   "StopId":64}
]

If it did return that, our code would work fine. The question is, do we want to make a stink about it, or just handle the problem on our end?

[sherson]

I added this to the list of issues I'm sending to Avail this week. I doubt they willl I'm certain they won't have a fix in place before Dec 25 or Jan 1, but let's see what they say.

[sherson]

I talked to the Avail Project manager; they're looking into it. I'll find out Tuesday if we need to handle it ourselves.

[bcspragu]

If you don't hear back, it's easy enough to code it in a way that handles both cases at once.

[werebus]

Yeah, I told @sherson that it wouldn't be any difficulty to code around. It's just that the API really is where a fix should be made since deviation from the API spec is a bug on their part.

That being said, it's an easy fix on our part that won't break when if Avail fixes it on their end. I'd say that we should roll out a fix before Christmas day.

[werebus]

Fixed on our end by #20, but leaving open until we get an answer from Avail.

[sherson]

:+1:

[sherson]

Avail can't fix it quickly. An interesting email excerpt:

To fill in a little of the background, what we are doing now is based on using the standard Microsoft tools and what they return in this case. That being said, we are certainly willing to investigate further, and determine if there is another industry best practice for handling this type of situation, and if so determine how / when we could implement a change. We would not be able to start that until after Jan 1, however.

I'd already let them know there was no rush (since a fix was ready to go).

Anyway, I just skimmed the InfoPoint REST EndPoints documentation again... I believe the only relevant text is:

If no data exists and [sic] empty result set will be returned.

Based on their response, I expect they'll just clarify that. Anyway, we're all set, so issue closed.

[werebus]

If no data exists and [sic] empty result set will be returned.

Well, that could arguably be said to describe the current behavior. I retract my claim that Avail was not adhering to their specification, although I maintain that it's not really sensible behavior.