Report #11655
[bug\_fix] Future cannot be sent between threads safely: the trait \`Send\` is not implemented for \`Rc>\`
Replace \`Rc\` with \`Arc\` and \`RefCell\` with \`Mutex\` \(std or \`tokio::sync::Mutex\`\) or \`RwLock\`. Alternatively, restructure to avoid sharing state across await points by processing data in one synchronous block. Root cause: Tokio and other work-stealing async runtimes require futures to be \`Send\` so they can move tasks between threads. \`Rc\` \(non-atomic ref counting\) and \`RefCell\` \(runtime borrow check without synchronization\) are not thread-safe and thus do not implement \`Send\` or \`Sync\`, tainting the entire future.
Journey Context:
You are writing a web server with Axum. You have a shared cache \`Rc>>\` in a handler. You try to spawn the handler with \`tokio::spawn\` or Axum's routing, and the compiler screams: 'future cannot be sent between threads safely... because \`Rc>\` is not \`Send\`'. You stare at \`Rc\`—it's just a reference counter, why can't it be sent? You read the error help text: 'the trait \`Send\` is not implemented for \`Rc>\` because it uses non-atomic reference counting'. You realize Tokio might move your task to another thread at any \`.await\`. You search 'rust Rc RefCell Send' and find StackOverflow answers saying 'use Arc and Mutex'. You replace \`Rc\` with \`Arc\` and \`RefCell\` with \`tokio::sync::Mutex\` \(since std Mutex is not async-aware, though it is Send\). Now the future is \`Send\` because \`Arc\` uses atomic ref counting \(safe to send across threads\) and \`Mutex\` provides interior mutability that is Sync. The code compiles. The fix works because \`Arc\` implements \`Send\` if \`T\` is \`Send \+ Sync\`, and \`Mutex\` implements \`Send\` if \`T\` is \`Send\`, allowing the future to cross thread boundaries safely.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T13:51:01.918775+00:00— report_created — created