EPG123 throws exception when SD is down

[12noon]

FYI, my 1.3.6.20 EPG123 client crashed because it was unable to request an SD token (when the SD database was offline).

Code: Select all

7:45:01 AM - Beginning EPG123 update execution. 2020-04-20 12:45:01Z
7:45:02 AM - Object reference not set to an instance of an object.
7:45:02 AM - Failed to retrieve token from Schedules Direct. message: Object reference not set to an instance of an object.

[garyan2]

That is soooo 12 hours ago. viewtopic.php?f=99&t=12980 (well, more like 6 hours, and there are still some aftershocks, but looks like we're good now).

jk

[12noon]

I know about SD's outage. I'm pointing out that EPG123 doesn't handle such outages as well as it could. That thread does contain a passing reference to this exception, but it was more concerned with SD being down that EPG123's issue. It might be better if EPG123 could say, "Sorry, SD is down. Try again in an hour." (SD's API doc recommends trying again in an hour.)

[garyan2]

There were a lot of things going on with the SD servers, and funny stuff happening when it was only partially up. Your log entry basically says that the response from SD was invalid. EPG123 handled it quite well as far as I can see. If you look in the other thread, if EPG123 received a valid response saying that SD servers were down for maintenance, it would have put that information in the log. With only an invalid response to go on, EPG123 doesn't know what is going on.

[12noon]

Well, the log says "Object reference not set to an instance of an object." which is an ArgumentNullException. I just thought you'd want to examine the return value instead of catching a null exception to handle the SD server being down. It's cool--to each their own.

[garyan2]

No bother, it's just I want to point out that the error is not due to the server outage, but due to an invalid response from SD. Due to the way I coded the messages in EPG123, the response has to be well defined. An invalid message like this is liking trying to fit a square peg in a round hole and it throws an exception. Since the peg doesn't fit, the response is null.

Basically, again, the error you got had nothing to due with the servers being down for maintenance. Something was working to give us a response, just not the right kind of response.

[12noon]

I think I'm not being clear. If I am, I apologize for trying to explain more clearly. Feel free to ignore it.

Schedules Direct's server returned this response to the /status request during the outage:

Code: Select all

{
	"response":"SERVICE_OFFLINE",
	"code":3000,
	"serverID":"20141201.web.1",
	"message":"Server offline for
maintenance.",
	"datetime":"2020-04-20T15:16:42Z",
	"token":"xxxxxxxxxxxxxxxxxxxxxxxx"
}

It's possible to parse that response because Typecast (my own app) was able to do it. Even if the HTTP request failed or returned some bogus response, it's still possible to catch the WebException or HttpRequestException. I'm probably missing something, but I don't really see the need for the client to dereference a null and crash. Any handle can be tested for null, no?

[garyan2]

Ah, so my turn. I see what you are saying and I do that.

Here's the way it goes for my code.
1) If a web exception is thrown, I do catch and parse the response. The log entry will be "SD API WebException Thrown. Message: {0} , Status: {1}". If the response is in the SD error message format like you posted above, it will add another log entry of "SD responded with error code: {0} , message: {1} , serverID: {2} , datetime: {3}". Here is an example of a WebException.

Code: Select all

[1/3/2020 4:22:02 AM] [ INFO] SD API WebException Thrown. Message: The remote server returned an error: (400) Bad Request. , Status: ProtocolError
[1/3/2020 4:22:02 AM] [ INFO] SD responded with error code: 4102 , message: No lineups have been added to this account. , serverID: 20141201.web.1 , datetime: 2020-01-03T11:22:02Z

2) If a response is received, and there is no exception, then it will evaluate the "code" of the message to integer 0. If not 0, then it will report the status like I got for yesterday mornings update. This is what you are saying should happen and it does happen.

Code: Select all

[4/19/2020 4:22:01 AM] [ERROR] Failed token request. code: 3000 , message: Server offline for maintenance. , datetime: 2020-04-19T11:22:01Z
[4/19/2020 4:22:01 AM] [ERROR] Failed to retrieve token from Schedules Direct. message: Failed token request. code: 3000 , message: Server offline for maintenance. , datetime: 2020-04-19T11:22:01Z

3) If the status code is 0, but the response serverID is null, then it will throw a null exception. (this is only because for a successful token request, I will log the serverId in the trace.log)

#3 may be where your exception got thrown. It didn't get a web exception, and the status response was 0, but it was still invalid/incomplete. This is not something that could reasonably be expected; to have a successful token request without a server.

Now I don't evaluate the status code for all message returns, just the /token, /status, /version, /lineups, and adding/removing a lineup. So we can certainly say there is a gap there in the logging for the other messages.