compile error with !Send handler shows none useful clue

[mineralres]

Bug Report

Version

0.23

Platform

Linux dev01 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Description

I have a minimal reproduction ,
https://github.com/mineralres/axum/tree/share-state-test (branch: share-state-test)
cd examples/error-handling-and-dependency-injection
cargo build
get the next comile error

[mineralres]

change sync::Mutex to tokio::sync::Mutex will fix the problem, maybe because std::sync::Mutex is not Send

[mineralres]

I have update the code:

1. Replace std::sync::Mutex to tokio::sync::Mutex will fix the first problem.
2. Import redis crate, and build a struct DbTest with conn, then call the DbTest.test().await, will get the same compile error as above, so i can't get any clue from the compile error , and have to split and comment some piece of the code to "find" the problem

3. Replace test(&self) with test(self) will fix the compile problem, it's clear that all my confuse was caused by !Send in hander functions , but the compile error will get the similar error output, without any useful clear clue. However, the compiler will output clear clue when i was using actix-web.
4. By the way, Send is a strict limit in my scene, hope there is more example to show how to overcome these difficulties! @davidpdrsn

[davidpdrsn]

axum does not allow !Send futures in handlers. If we were allow to that none of the futures axum creates internally would be Send meaning tokio's multithreaded runtime couldn't move them around.

From the tokio docs on Mutex:

Note that, although the compiler will not prevent the std Mutex from holding its guard across .await points in situations where the task is not movable between threads, this virtually never leads to correct concurrent code in practice as it can easily lead to deadlocks.

But tbh I haven't benchmarked or investigated this further as I didn't consider it much of an issue, although a few asked about it. I think the general recommendation is to use a non-async mutex if you're not doing IO while holding the lock otherwise use an actor to coordinate access.

And yes the type error is very very bad 😞 Unfortunately there is nothing we can do in axum to improve that. The machinery that makes variadic handler functions work really hurts the error messages.

[mineralres]

At least,hope there is any method to get the clear type compil error output, otherwise it's too hard for axum beginners!

[davidpdrsn]

I'm not aware of any.

[davidpdrsn]

I'll close this issue for now. I'm not sure there is much we can do. Would like to hear from someone who has ideas.