Porting to v0.5 - alternative startup

[InstinctBas]

Hi All,

I'm nearly done with converting my rocket project to v0.5 but ran into a snag mostly due to not fully comprehending some of the new async/ignite/launch stuff.

My current v0.4 main function performs a whole bunch of startup stuff before it even comes to rocket. Checking my database, performing upgrades of tables, doing some maintenance, all the fun stuff associated with running up a new version.

At the end, if all is well, I start rocket.

So in my case #[launch] does not seem an option, the code that builds rocket is shared with my test suite in which I do not want to run through most of the startup code.

I settled on:

fn myrocket() -> rocket::Rocket<rocker::Build> {
  let r = rocket::Build()
    .mount(...)
    
  // Do a bunch more mounts and attaching and stuff
   
  r
}

#[rocket::main]
async fn main() -> Result<(), rocket::Error> {
  let mut start_server = true;
  
  // Do all my init and stuff here


  if start_server {
    let _r = myrocket()
      .ignite().await?
      .launch().await?;
  }

  Ok(())
}

However when attempting to run I get:

thread 'main' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', /Users/bastiaanolij/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.19.2/src/runtime/enter.rs:39:9

It seems to be running fully through my startup code and initialising rocket, so it may be completely unrelated to how I've setup my startup code, but it's one difference that stood out.

If anyone has any tips on what I may be doing wrong here, that be great :)
Thanks!
Bas

[oharedrobin]

I think it doesn't matter, whether you use #[launch] or #[rocket::main]. They both initialize the tokio runtime. However, it seems there is another place in your code, where this happens. Could you please check?

In my project, I put the build_rocket() function (where the startup stuff happens) in lib.rs and my main.rs just contains:

#[macro_use]
extern crate rocket;

use my_crate::build_rocket;

#[launch]
fn launch() -> _ {
    build_rocket()
}

This also works with integration tests.

[InstinctBas]

Sorry for the late reply, I was traveling.

Ok changing the way we start doesn't seem to make a difference. I traced it to a call to postgres::Client::query that I do before rocket starts as I'm checking a few things in the database. It looks like it doesn't like this when its starting tokio, I guess because postgres attempt to run queries in a separate thread as well..

A bit of a pain because this code should be run before tokio starts but we don't seem to have that ability...

[SergioBenitez]

Have you looked at the databases example in the repository? It's a good template to follow. In particular, running database actions in fairings.

Otherwise, consider using the execute function to start the async runtime when you're ready, and not before.

[InstinctBas]

Thanks sergio, I'll have a closer look. The problem is that we have an existing code base that we've been maintaining for several years so it's a bit of a pain having to change it drastically.

[InstinctBas]

it's also a PITA that we're trying to run a number of sanity and upgrade checks on the database before rocket even starts and this seems to get twarted in similar ways.

[SergioBenitez]

0.5 lets you do a lot of things in a cleaner and more robust manner. Going to async does mean that you'll need to make changes to your code, and at times those changes might be onerous if your code was making a lot of assumptions, but Rocket shields you from it as much as possible, and more so than you'll find in any other framework. I encourage having an open mind and taking a closer look at the examples, documentation, and migration guide.

[InstinctBas]

I guess thats where my problem lies, some of these don't have clear examples that really match what we've done in the past, so trying to figure out what the right path forward is takes some time. I'm sure that once I find it I fully agree it's a good approach :)

[InstinctBas]

Ok, quick little update now that we've made some progress here.

The culprit turned out to be the Postgres crate we were using. This is actually a wrapper around tokio-postgres to turn an asynchronous implementation into a synchronous implementation, the opposite of what we need today :).
So we've switched over to using tokio-postgres directly and refactored nearly our entire API to use async :)

Plenty of stuff to polish up but it looks like it's breathing now :)

[InstinctBas]

Thanks for the help everyone. Getting a hang of it all now and pretty much through the first migration pass :)