2020-10-26 20:29:36 +00:00
|
|
|
#[rocket::async_test]
|
|
|
|
async fn test_await_timer_inside_attach() {
|
|
|
|
|
|
|
|
async fn do_async_setup() {
|
|
|
|
// By using a timer or I/O resource, we ensure that do_async_setup will
|
|
|
|
// deadlock if no thread is able to tick the time or I/O drivers.
|
2020-12-24 01:02:40 +00:00
|
|
|
rocket::tokio::time::sleep(std::time::Duration::from_millis(100)).await;
|
2020-10-26 20:29:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
rocket::ignite()
|
Remove 'attach' fairings. Add 'liftoff' fairings.
Launch fairings are now fallible and take the place of attach fairings,
but they are only run, as the name implies, at launch time.
This is is a fundamental shift from eager execution of set-up routines,
including the now defunct attach fairings, to lazy execution,
precipitated by the transition to `async`. The previous functionality,
while simple, caused grave issues:
1. A instance of 'Rocket' with async attach fairings requires an async
runtime to be constructed.
2. The instance is accessible in non-async contexts.
3. The async attach fairings have no runtime in which to be run.
Here's an example:
```rust
let rocket = rocket::ignite()
.attach(AttachFairing::from(|rocket| async {
Ok(rocket.manage(load_from_network::<T>().await))
}));
let state = rocket.state::<T>();
```
This had no real meaning previously yet was accepted by running the
attach fairing future in an isolated runtime. In isolation, this causes
no issue, but when attach fairing futures share reactor state with other
futures in Rocket, panics ensue.
The new Rocket application lifecycle is this:
* Build - A Rocket instance is constructed. No fairings are run.
* Ignition - All launch fairings are run.
* Liftoff - If all launch fairings succeeded, the server is started.
New 'liftoff' fairings are run in this third phase.
2021-04-01 19:32:52 +00:00
|
|
|
.attach(rocket::fairing::AdHoc::on_launch("1", |rocket| async {
|
2020-10-26 20:29:36 +00:00
|
|
|
do_async_setup().await;
|
|
|
|
Ok(rocket)
|
|
|
|
}));
|
|
|
|
}
|