Calling async while implementing sync trait

[Geobomatic]

This question is similar to Sync function invoking async but I'm seeking advice anyway:

I'm implementing this trait https://docs.rs/oxide-auth/0.5.0-preview.0/oxide_auth/endpoint/trait.OwnerSolicitor.html and inside, I can call async version of an API to access an LDAP server (using ldap3 0.7-alpha7).

The sync version of ldap3 0.7 does a block_on and as my trait implementation already run in Tokio executor (through warp) I would need to use spawn_blocking as suggested here but I'm wondering if there is a way to call the async version of ldap3 in my trait implementation so I won't block.

[daboross]

Short of completely changing oxide-auth's API, I don't think there's much we can do here. It exposes a fully synchronous interface and it'd be pretty hard to reach through that synchronous interface to perform an async operation. I mean, to do an await, the whole call stack up to the executor needs to be able to be stored in a Future so it can be paused and resumed. If everything's an async fn, then that just works. But if there's some layer which is fully synchronous, and doesn't allow returning a Future to poll, then there isn't really any way to transform that layer into a future besides straight up rewriting it, or writing an alternative.

[Geobomatic]

I was afraid of that, maybe oxide-auth will evolve someday (I can see an async branch). Thank you!

[Geobomatic]

Hm, I can't find a way out of this issue. I created an example: https://github.com/inejge/ldap3/files/4695777/example.zip

Once running, if you hit http://localhost:4321/fct1
it panics because of "runtime inside runtime" error.

[alice]

Blocking code must run in spawn_blocking.

async move {
    tokio::task::spawn_blocking(move || {
        fct1(&cfg, params)
    })
        .await
        .unwrap()
        .and_then(|response| Ok(response))
        .or_else(|e| Err(warp::reject::custom::<ServerError>(e.into())))
}

[Geobomatic]

Ok, I need to go to the root of the "async stack"… I was trying to squeeze spawn_blocking at some_method and it obviously gone wrong ^^ thanks @alice!