Error(BlockingClientInFutureContext, when using api from within actix handler

[vigneshsarma]

Minimal code that causes this error is here, https://gist.github.com/vigneshsarma/426074f7e5bf76518be302bc4d8ff4ca

I am running on macos and kubernetes server is minikube and version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T18:55:03Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:36:19Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

Sample run:

$ RUST_BACKTRACE=1 POD_NAMESPACE=test cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.62s
     Running `target/debug/foo`
Jobs: "test-0-job"
Jobs: "test-1-job"
thread 'actix-rt:worker:0' panicked at 'called `Result::unwrap()` on an `Err` value: Error { inner: Error(BlockingClientInFutureContext, "https://192.168.198.128:8443/apis/batch/v1/namespaces/test/jobs?")

Error executing request }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Panic in Arbiter thread, shutting down system.

invoke the endpoint by calling curl http://localhost:6666/foo/.

Full stacktrace is in the gist.

As you can see the ls_jobs call works outside the actix web server context, while the exact same call fails inside.

Any idea what might be wrong?

[clux]

Interesting! I guess this makes sense because the actix routes are futures in 1.0 ?
This certainly looks like a way of making sure you don't call blocking code inside a future, (similar code is found in reqwest).

It makes sense that you would get this; actix has async handlers and the kube is very much synchronous at the moment. If you wrap your ls_jobs call up in a future I would anticipate the problem goes away.

I would look into moving kube over to async as soon as the ecosystem stabilises, but you'd have to wait a little bit for that.

[vigneshsarma]

So in my actual program, I am calling a https://docs.rs/rusoto/ call and that goes through fine. Looking at the code it looks like they are also using reqwest. But it looks like they do wrap each call with Future even though as a user I have a synchronous interface.

Would you happen to have an example code for wrapping something like ls_jobs with Future?

[jnicholls]

@clux Most of the ecosystem necessary to do this (reqwest, tokio, etc.) have builds that support a fully future (async/await) interface. It would be amazing for this client to support:

1. reqwest's async client
2. returning futures on the api surface that call down to the async reqwest client under-the-hood.

[clux]

It's certainly something we want to do. But I'm not going to try this until async / await syntax reaches stable in 1.39. Happy to take PRs for it in the mean time though!

[wonderflow]

Do we have any way to work around it?

[clux]

basic async/await support now in kube=0.18.0. have updated all examples and https://github.com/clux/controller-rs/ to show how to use it on stable (see https://github.com/clux/controller-rs/pull/6/files )

a proper streaming watch api is still TODO, so while it's not functionally giving a big performance improvement, it's at least a step in the right direction and it should be useable within async contexts.

For the performance win, please take discussions on a proper streaming API to #83.

[wonderflow]

cool!