Comment 4 for bug 956132

Hmm, I'm not sure that would be a good solution. The started deferred is waited on by AMQClient.start method, so it must be fired at some point on startup. And when it's fired, it can't be turned into an errback.
Since the basic_publish call can fail any time, I don't think using a "started" deferred would be a good way (looks like hijacking to me ;-)). Actually, from my point of view it really looks like an event that happens in the system and should be handled by a callback. What to do with this callback, however, is pretty unknown to me. In my application I've chosen to completely disconnect and have a ReconnectingClientFactory reconnect for me, but that's just my use case. Other people may prefer opening another channel, or link the "reason" message to the actual sent message, or whatever.
That's why I'm proposing a non-implemented callback.