CppCon 2026

What makes an async workflow readable? Not just linear control flow‚ you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow‚ multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling‚ and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?

Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task<expected<T, E>> separates async completion from domain failure into orthogonal axes: errors short-circuit through monadic composition (and_then/or_else), and each step has a pure-functional signature that developers on the team can read, test, and extend. The combination‚ coroutines for structure, expected for error flow‚ is what makes the workflow genuinely readable.

Attendees will leave with: (1) the two-axis decomposition (async completion vs. domain outcome) and why separating them changes how you design every step, (2) a four-question framework for evaluating any async architecture, and (3) concrete patterns for partial-failure handling in coroutine fan-out.