when_any doesn't cancel children tasks on error

[anarthal]

#include <boost/capy/error.hpp>
#include <boost/capy/ex/async_event.hpp>
#include <boost/capy/ex/run_async.hpp>
#include <boost/capy/ex/thread_pool.hpp>
#include <boost/capy/io_task.hpp>
#include <boost/capy/task.hpp>
#include <boost/capy/when_any.hpp>

#include <iostream>

namespace capy = boost::capy;

// Returns immediately with a canceled error.
capy::io_task<> fn1() { co_return {capy::error::canceled}; }

// Waits on an event that is never triggered.
capy::io_task<> fn2()
{
   capy::async_event evt;
   co_return co_await evt.wait();
}

// BUG: This hangs. `when_any` should complete as soon as `fn1()`
// returns, cancelling `fn2()`. Instead, `mytest()` never returns.
capy::task<> mytest()
{
   auto u = co_await capy::when_any(fn1(), fn2());
   std::cout << "Index: " << u.index() << std::endl;
}

int main()
{
   capy::thread_pool ctx;
   capy::run_async(ctx.get_executor())(mytest());
   ctx.join();
}

Expectation: fn2 gets cancelled, mytest finishes.
Actual behavior: mytest will never complete.

This behavior doesn't happen if f1 finishes successfully.

Prevents the Boost.Redis port from working.

[mvandeberg]

This is a purposeful design decision. https://github.com/cppalliance/capy/blob/develop/doc/combinator-spec.md

You can wrap the inner awaitable to interpret the error as a success.

capy::io_task<> inner_fn1()
{
    co_return {capy::error::canceled};
}

capy::io_task<> fn1()
{
    auto [ec] = co_await inner_fn1();
    if (ec == capy::cond::canceled)
        co_return {};    // translate to success. when_any sees a winner
    co_return {ec};      // propagate other errors as-is
}

If you need the inner error code, you can return it via io_task<std::error_code>.

// Wrapper: lifts the inner ec into a value so when_any always
// sees success. The caller gets the original ec as a payload.
capy::io_task<std::error_code> fn1()
{
    auto [ec] = co_await inner_fn1();
    co_return {{}, ec};
}

Leaving open to add future documentation of these patterns.

[anarthal]

Oh, that changed since the last time then. I can see the documentation has been updated since then, so apologies.

This means that when_any is now equivalent to asio::experimental::wait_for_one_success, rather than wait_for_one. I understand that I can emulate wait_for_one semantics with the patterns that you've provided. Would it be viable implementing a native primitive with wait_for_one semantics? Propagating the error with this approach looks a little bit dirty.

Thanks for your help.