I am working on building a rocket REST API using a mongodb database. I have been able to successfully create a connection and start up the server without errors:
# Cargo.toml
[dependencies]
rocket = "0.5.0-rc.1"
dotenv = "0.15.0"
mongodb = "1.2.2"
[dependencies.openssl]
version = "0.10"
features = ["vendored"]
#[get("/")]
pub async fn index(client: &State<ClientPointer>) -> &'static str {
let _dbs = client.0.list_databases(None, None).await.unwrap();
"Fetched databases"
}
#[launch]
async fn rocket() -> _ {
let client = database::connect::pool(1, 32).await.unwrap();
rocket::build()
.mount("/", routes!(routes::index))
.manage(database::rocket::ClientPointer(client))
}
However, when the route is invoked I get the following output:
>> Matched: (index) GET /
thread 'rocket-worker-thread' panicked at 'there is no timer running, must be called from the context of a Tokio 0.2.x runtime', C:\Users\lukasdiegelmann\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.2.25\src\time\driver\handle.rs:24:32
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
>> Handler index panicked.
>> This is an application bug.
>> A panic in Rust must be treated as an exceptional event.
>> Panicking is not a suitable error handling mechanism.
>> Unwinding, the result of a panic, is an expensive operation.
>> Panics will severely degrade application performance.
>> Instead of panicking, return `Option` and/or `Result`.
>> Values of either type can be returned directly from handlers.
>> A panic is treated as an internal server error.
>> Outcome: Failure
>> No 500 catcher registered. Using Rocket default.
>> Response succeeded.
So it seems like there is something wrong with the versioning of the used async runtime. But I could not find where, because the error do not really give me a hint and the mongodb rust driver appears to be using a 0.2.x version of tokio namely version ~0.2.18.
Edit: I have gained a little bit more insight and it seems like rocket-0.5.0-rc.1 has started using a tokio-1.x runtime, whereas mongodb-1.2.2 has not. This obviously imposes a big problem, since I will either have to have two runtimes run simultaneously or have to ditch mongodb for now, which is not exactly the definition of a solution.
