tokio-async-code-review

Tokio Async Code Review

Review Workflow

1. Check Cargo.toml — Note tokio feature flags (full, rt-multi-thread, macros, sync, etc.). Missing features cause confusing compile errors.
2. Check runtime setup — Is #[tokio::main] or manual runtime construction used? Multi-thread vs current-thread?
3. Scan for blocking — Search for std::fs, std::net, std::thread::sleep, CPU-heavy loops in async functions.
4. Check channel usage — Match channel type to communication pattern (mpsc, broadcast, oneshot, watch).
5. Check sync primitives — Verify correct mutex type, proper guard lifetimes, no deadlock potential.

Gates (objective passes before conclusions)

Complete in order for the review scope. Do not assert Critical or Major until the relevant gate passes.

1. Dependency surface — Read the crate (and workspace, if inherited) Cargo.toml that supplies tokio. Pass: Written note of tokio version and enabled features, or explicit statement that there is no direct tokio dependency and where it comes from (workspace/path).
2. Runtime model — Locate runtime construction (#[tokio::main], Runtime::builder, tests, or library with no owned runtime). Pass: One line naming flavor (multi_thread / current_thread / tests-only / none) and where it is defined.
3. Blocking inventory — Search reviewed paths for blocking APIs (std::fs::, std::net:: without async wrappers, std::thread::sleep, heavy CPU loops in async fn). Pass: Each hit listed as path:line (or tool output excerpt), or explicit “no blocking patterns found in reviewed async code” after the search.
4. Protocol — Load the review-verification-protocol skill. Pass: Its pass conditions met before any finding is reported (file:line evidence for asserted issues).

Output Format

Report findings as:

[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.