Great!

Could we also ensure that failure messages do not create additional error messages that contain the same data perhaps? Or is this intentional, so that one is for the software to read, and the other one actually for the user?

I believe this question is still open? (Just generally, not blocking this PR.)

Could we also ensure that failure messages do not create additional error messages that contain the same data perhaps? Or is this intentional, so that one is for the software to read, and the other one actually for the user?

@galfert @raucao - OK, I've simplified things:

1. Any job failures, callback is used. In XMPP I was using both the cb() and sendToClient, for no reason other than to be confusing I guess.
2. Platform.ts ensures that the callback can only be used once (ignores subsequent calls)
3. Don't throw an error when not necessary, instead use fail callback.

Can I get a final OK just to be sure?

OK, so now I found out why Hyperchannel isn't logging the failure messages for the connect. Instead of the normal "failure" event name, which other failures do use, this one uses the event name "failed".

I think we need to manually ensure that these are all consistent for now. But in the future, trying to send unknown event names should probably cause at least a console warning, or ideally a linting error.