FWIW, your timeout handler if-check is somewhat redundant.
You're capturing the expiry by value (as you have to -- you can't
capture it by reference since you're moving the lifetime of the timer),
which means that it will always be less than the current time, unless
the timer was aborted early due to some error other than operation_aborted.
There isn't any code that can change the expiration time seen by the
lambda callback (which the comment expresses as the reason for the check).
Thanks for pointing this out. The code was copy-pasted around much throughout my efforts and I suppose the comment referred to some other place where I followed the pattern the asio examples do by re-using the same timeout again for different ops and reset the expiry time. I will correct this. You are right. Since it's only used once I don't need the check, so the comment is wrong.
I'm in the process of creating more such composed ops for ever recurring use cases and perhaps I find a way to tie this lambdas lifetime to the whole operation. As it happens, my gut felling tells me there are cases when the timer lambda will dangle around and potentially crash, perhaps when the op is used and the io_service being destroyed and not polled before destruction. I couldn't verify this in the unit test yet but there's often cases like this that go overlooked.
Cheers,
Stephan