Why we're doing this?

This is not a necessary step because the channel still be destructed at the end of the async task, but I decided to drop it earlier as we can destruct the channel using drop because anyway we can't write to it anymore if there is an error in it.

We're setting this to true only here. Does that mean that after any failed ping we would need a new call to messages_stream? Is that ok?

Yes, we are setting the online to true only on the successful connection. If the channel is dropped in a ping loop or another write we are marking it as false. If the client reconnects the true status will be updated by this line. There are no other reasons to mark the client online except for the successful connection to the channel. I've tested this a lot by connecting to the channel, dropping the network, dropping the connection, reconnecting, etc. it works as expected for any reason.

The same approach was in the C++ handler and we had a long discussion before about that )

What is the benefit of using explicit drop? In almost all the cases we should let the object go out of scope - is this case somehow different and dropping is beneficial? For me it seems like a premature optimization, but maybe I'm missing something.

Yes, it will be dropped at the end if it goes out of scope. The only benefit here is that we are not waiting for that and dropping it earlier.

For me it seems like a premature optimization

Maybe it is. I do not insist on this, so I just removed the drop )

As a side note, I'm not sure if this code does what you think it does. Drop just takes an ownership of an object, and if that results in object going out of scope, then the destructor is called. tx_writer takes channel by reference so this call is probably useless. Could you check that?

Drop is just a destructor of the channel copy in our case.