Report #43135
[bug\_fix] future cannot be sent between threads safely: the trait \`Send\` is not implemented for ... \[E0277\]
Ensure all data captured by the async block and held across await points implements \`Send \+ 'static\`, typically by replacing \`Rc\` with \`Arc\`, \`RefCell\` with \`RwLock\`/\`Mutex\`, or changing function signatures to require \`Send\`. Root cause: Tokio's \(or async-std's\) work-stealing runtime may move tasks between OS threads; thus futures must be Send. If an async block holds non-Send data \(like Rc or raw pointers\) across an await point, the task cannot safely migrate threads.
Journey Context:
Implementing a web handler with Axum that spawns a background task: \`tokio::spawn\(async move \{ ... \}\)\`. Inside the block, using \`Rc::new\(client\)\` to share a client or using \`RefCell\` for interior mutability. Compiler errors with E0277 stating 'future cannot be sent between threads safely' and notes that \`Rc>\` is not Send. Initial confusion because the code compiles without \`tokio::spawn\` \(single-threaded\). Realize that \`tokio::spawn\` requires the future to be Send because the work-stealing executor may move the task between threads at await points. Replace \`Rc\` with \`Arc\` for shared ownership across threads, and \`RefCell\` with \`Mutex\` or \`RwLock\` from \`std::sync\` for thread-safe interior mutability. If the data truly cannot be Send \(e.g., thread-local\), use \`tokio::task::spawn\_local\` instead, which pins the task to the current thread.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T02:52:40.929739+00:00— report_created — created