Function block_on_ready 

pub fn block_on_ready<F>(fut: F) -> F::Output
where
    F: Future + Send,
    F::Output: Send,

Run an async future to completion from inside a synchronous Plugin::on_ready implementation.

Plugin::on_ready is a sync trait method (the trait has to be object-safe for Vec<Box<dyn Plugin>>), but most real-world async work — schema DDL via sqlx, policy setup, initial seeding — needs to await. This helper bridges that gap safely under every runtime configuration that umbral encounters in practice:

Caller context	Bridge used
Multi-thread tokio runtime (#[tokio::main], prod binaries)	tokio::task::block_in_place + Handle::block_on — parks the OS thread, doesn’t block the executor
Current-thread tokio runtime (#[tokio::test] default)	Spawns a dedicated OS thread with its own Runtime; block_in_place would panic here
No ambient runtime (bare main, exotic callers)	Creates a temporary Runtime and block_ons

Why not just Handle::current().block_on(fut)?

block_on on a Handle panics when called from within a current-thread runtime (which is the default for #[tokio::test]). The multi-thread path requires block_in_place to hand control back to the executor; the current-thread path requires moving to a different OS thread entirely.

Usage

fn on_ready(&self, ctx: &AppContext) -> Result<(), PluginError> {
    umbral::plugin::block_on_ready(self.do_async_setup(&ctx.pool))?;
    Ok(())
}