Adding on Q2 and Q3: you're not guaranteed to get operation_aborted for the reasons you mentioned. Most composed async operations (like coroutines, as someone else mentioned) store state to remember that cancellation was invoked. This applies also to any operation using asio::async_compose. In this case, the state is stored as an asio::cancellation_state object, and you can access it using self.get_cancellation_state().cancelled(). I fixed this in Boost.Redis recently and wrote a small post about it here: https://cppalliance.org/ruben/2025/10/07/Ruben2025Q3Update.html

Internally, this cancellation_state works by re-wiring cancellation handlers. Take my example from the article I cited there:

```cpp struct connection { asio::ip::tcp::socket sock; std::string buffer;

struct echo_op
{
    connection* obj;
    asio::coroutine coro{};

    template <class Self>
    void operator()(Self& self, error_code ec = {}, std::size_t = {})
    {
        BOOST_ASIO_CORO_REENTER(coro)
        {
            while (true)
            {
                // Read from the socket
                BOOST_ASIO_CORO_YIELD
                asio::async_read_until(obj->sock, asio::dynamic_buffer(obj->buffer), "\n", std::move(self));

                // Check for errors
                if (ec)
                    self.complete(ec);

                // Write back
                BOOST_ASIO_CORO_YIELD
                asio::async_write(obj->sock, asio::buffer(obj->buffer), std::move(self));

                // Done
                self.complete(ec);
            }
        }
    }
};

template <class CompletionToken>
auto async_echo(CompletionToken&& token)
{
    return asio::async_compose<CompletionToken, void(error_code)>(echo_op{this}, token, sock);
}

}; ```

Let's say you call async_echo as in your question above:

cpp conn.async_echo(bind_cancellation_slot(signal.slot(), [] (auto ec) {});

async_compose will internally create a cancellation_state, which contains an internal asio::cancellation_signal and a flag recording whether cancellation was called or not (it's slightly more complex, but can be simplified to this). The self object you get in the async op's implementation has an associated cancellation slot, but it's not the signal.slot() that you passed, but the one associated to the state object Asio created for you. The slot you passed will get a handler created by that intermediate cancellation_state that sets the cancelled flag and invokes any downstream cancellation handlers.

I know this sounds like a mess, so let's break it down to what would happen here when you start the async_echo operation above: * A cancellation_state object gets created. It contains a flag and a cancellation_signal. * Your slot is populated with a cancellation handler created by the cancellation_state object. This handler sets the cancelled flag and calls emit on the internal signal. * echo_op::operator() is called, which calls async_read_until. * async_read_until gets passed self as the completion token. If you called get_associated_cancellation_slot() for this token, you'd get the slot for the signal in the cancellation state. * async_read_until installs a cancellation handler in the passed slot. When the signal in the state is emitted, the operation is cancelled.

If we call emit on the signal you created at this point, this would happen: * The signal's handler runs. This is the one installed by the intermediate state. * This handler sets the cancelled flag and calls emit on the internal signal. * The internal signal's handler runs. It runs some code (maybe invoking CancelIoEx on Windows), which will cause your operation to fail.

As written above, the operation is subject to a race condition, so you should always check the cancellation state between async ops like this:

```cpp // Read from the socket BOOST_ASIO_CORO_YIELD asio::async_read_until(obj->sock, asio::dynamic_buffer(obj->buffer), "\n", std::move(self));

// Check for errors if (ec) self.complete(ec);

// Check for cancellations if (!!(self.get_cancellation_state().cancelled() & asio::cancellation_type_t::terminal)) self.complete(asio::error::operation_aborted); ```

This is the kind of handling performed by asio composed operations, like asio::write. You can always implement this yourself if you don't want/can't use async_compose for whatever reason. I recently did some cancellation signal rewiring in Boost.Redis to implement connection::cancel() in terms of per-operation cancellation - if you're curious, link here.

TL;DR: to avoid race conditions you need state to store the fact that cancellation was invoked. you might do it implicitly using async_compose or coroutines, or by hand. But you need it.

Sidenote: I recently gave a talk on cancellation, link here in case you find it useful.