Error handling

[home-assistant-libs]

Error handling

[Raynes]

To add to this, the reason that I realized this was an issue is because I wrote a program to do some volume changes in response to other devices in the room turning on and off. Leaving this program running was an issue because upon losing connection to the chromecast commands begin to error.

The primary issue is that the first command you send doesn't error after a connection loss, just connection errors in a background thread then the next time you send a message you get a catchable exception, though the exception you get varies.

So basically:

• Start program, get cast object.
• Somewhere in the darkness, a squirrel nibbles on a cable. Cast loses connection.
• Air conditioner turns off, try to turn chromecast down. Looks like it succeeded! Connection errors in the background.
• A few hours later, the air conditioner turns back on and we try to turn up the chromecast volume. Broken pipe or some other error.

That's an unfortunate way to have to do error handling :p.

I'd be happy to try to help out with fixing these issues if we could discuss what we'd like to happen in these kinds of scenarios. In particular, I'd be fine just having to say "I'd like this command to block", but it'd need to be able to fail with an exception rather than hang forever. Furthermore, having to pass a blocking arg to everything seems unwieldily. Usually, I feel like I'm going to want to block. What things would I want to do and not know if they succeeded or not, right?

[balloob]

Socket error handling is pretty non-existent at the moment and should indeed be improved. In an ideal world it would try to reconnect whenever the connection gets lost. We should be able to detect if the connection is lost because the _read_message will start throwing errors.

If a connection is lost the run method in socket client could start the process of reconnecting to the Cast device and raise exceptions on all calls to send_message.

One of the reason why I don't have commands block by default is because it is unsure to me what the different edge scenarios are. Current blocking works by adding a requestId attribute to the message we are sending out and then wait till we get a response that refers to our requestId (set id, callback based on id). With this in mind, how would one act if we lose the connection and thus will never get a result back. Would the blocking timeout and return without a result? Should the blocking method raise an exception? The last one feels like a proper solution to me but depends on detecting when the connection is lost.

[rcludwick]

If the socket fails, you probably want it to fail early, so you can reconnect quickly. In ubuntu it might be a while before you know whether or not a socket fails. This is controlled by tcp keepalive defaults in sysctl (which can be overridden by setsockopt). A 2 second keepalive time with an interval of 1 and a count of 3 seems reasonable on a local wireless network. This means that interactivity is preserved while you're trying to figure out if you need to reopen the socket.

With an ssh connection if the tcp connection dies, the shell on the remote end dies. If the expected behavior is like ssh, the socket layer should just throw an error which should propagate up to the application and let the application decide if it needs to reinitialize its state after restarting the socket or error out.

In other cases where the session survives tcp socket death (such as web sites using cookies for authentication), the application can simply restart the socket when the socket loses the connection. If the socket keeps failing and it can't send the same message, say, three times through three different sockets, then an exception is thrown to the application. The application should probably exit at this point because it's something that can't be fixed, like the chromecast being unplugged.

[Raynes]

This can be closed now. We've merged in reconnection/error handling.