Upgrade to recent Tokio version v1.0

[martinomburajr]

The issue here is that running this library when my application runs with a newer version of Tokio returns an error shown below

thread 'main' panicked at 'not currently running on a Tokio 0.2.x runtime.', /Users/martinomburajr/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.25/src/runtime/handle.rs:118:28
stack backtrace: ...

I am currently on v1 of the tokio library... Maybe it would be time to upgrade the dependencies if possible.

[Empty2k12]

@martinomburajr Thanks for raising this. I've been meaning to update all dependencies to the latest versions for a while. PRs open, if you want to do it :)

[martinomburajr]

Thanks for the response, Im still getting learning the language and it may take sometime for me to get to grips with it all, I'll try it when Im ready.

[Carter12s]

Also interested in this feature, also new to rust.

I'm going to attempt this this week, no idea what level of pain I'm in for.

[Carter12s]

Notes:
Core library builds fine with bumping influxdb and benches dev-dependencies on tokio to 1.4.0

However tests fail with:

there is no reactor running, must be called from the context of a Tokio 0.2.x runtime
thread 'test_ping_influx_db_tokio' panicked at 'there is no reactor running, must be called from the context of a Tokio 0.2.x runtime'

This is the same error I was getting when attempting to use this lib. Stack trace indicates error is originating from hyper-tls.

Inverting cargo tree to see where Tokio 2 is being pulled in results in:

$ cargo tree -i tokio:0.2.25
tokio v0.2.25
├── async-global-executor v2.0.2
│   └── async-std v1.9.0
│       ├── http-types v2.10.0
│       │   ├── http-client v6.3.5
│       │   │   └── surf v2.2.0
│       │   │       └── influxdb v0.4.0 (/home/carter/influxdb-rust/influxdb)
│       │   │           [dev-dependencies]
│       │   │           └── benches v0.0.0 (/home/carter/influxdb-rust/benches)
│       │   └── surf v2.2.0 (*)
│       └── surf v2.2.0 (*)
│       [dev-dependencies]
│       └── influxdb v0.4.0 (/home/carter/influxdb-rust/influxdb) (*)
├── h2 v0.2.7
│   └── hyper v0.13.10
│       ├── http-client v6.3.5 (*)
│       └── hyper-tls v0.4.3
│           └── http-client v6.3.5 (*)
├── hyper v0.13.10 (*)
├── hyper-tls v0.4.3 (*)
├── tokio-tls v0.3.1
│   └── hyper-tls v0.4.3 (*)
└── tokio-util v0.3.1
    └── h2 v0.2.7 (*)

As far as I can tell Surf is the only dependency that is blocking upgrade:

• Issue tracking their path to Tokio 1.x is here
• They are transitively blocked on hyper-rs

I think this is a dead end until hyper-rs does next major.

[let4be]

Sigh... cannot find a way to work with influxdb from rust, also relatively new to the language...
It also seems there is no good lib for 2.0 influx api

Maybe I try export my metrics in prometheus style and scrape them using influxdb scrappers for now

edit: changing my Cargo.toml to this influxdb = { version = "0.4.0", features = ["derive", "h1-client-rustls"] } (basically switching to another http client) made it work without panic
but I still cannot get data into influxdb(2.x) via a legacy api.. though client completes the write without errors and authentication seems to work

edit2: ok I managed to get data into influx using this library, there was a problem with v2 -> v1 api mapping (missing dbrp mapping) and for some reason influxdb-rust does not return an actual error from write call when this happens... it reports an okay status(no error) but shows an error message in json in the data of returned Result<String, Error> i.e. in String part...
that's bad

[Carter12s]

edit: changing my Cargo.toml to this influxdb = { version = "0.4.0", features = ["derive", "h1-client-rustls"] } (basically switching to another http client) made it work without panic
but I still cannot get data into influxdb(2.x) via a legacy api.. though client completes the write without errors and authentication seems to work

As an alternative I've been using tokio = { version = "0.2.25", features = ["full"] } which uses the default hyper-http client. It has been fully working for me. Note: while 0.2.x tokio uses an older style API it is still actively updated with last patch on Jan 28th.

edit2: ok I managed to get data into influx using this library, there was a problem with v2 -> v1 api mapping (missing dbrp mapping) and for some reason influxdb-rust does not return an actual error from write call when this happens... it reports an okay status(no error) but shows an error message in json in the data of returned Result<String, Error> i.e. in String part...

This is news to me, I'm working with the v1 api and haven't run across this. Agree that detecting the error in the json and returning a rust error would be an improvement. Would you be able to make an issue describing how to reproduce and what you think intended behavior should be?

[let4be]

I ended up using this library - https://github.com/voipir/rust-influxc
It has native support of influxdb 2.0 API but has no async support yet which I do not mind, - can write all data in a blocking way via tokio::task::spawn_blocking and simply send the data to this thread via a channel, it also does batch writes so blocking should not be an issue

I will look into creating a separate issue describing this error swallowing, it probably has to with using backward compatible API of influxdb(I'm running influxdb 2.0.4 and been using 1.x API where database is marshalled to a bucket via dbrp)

[altanozlu]

If you want to use tokio 1.x and this crate at the same time you can use this fork https://github.com/altanozlu/influxdb-rust
note: i don't mean to split community in here, it's just a workaround.
it uses tokio 1.x and reqwest 0.11

[modestmicha]

@altanozlu Your changes look great. Why don't you open a PR?

[altanozlu]

@altanozlu Your changes look great. Why don't you open a PR?

My fork is currently tokio only but this repo supports a lot of backends.

[kelnos]

Just FYI, for people who want to use tokio 1.x with the currently-released influxdb client, you can include the tokio-compat-02 crate, add use tokio_compat_02::FutureExt;, and then call .compat() on the Future returned from the influxdb query function.

Obviously the ideal is that this gets updated to use tokio 1.x, but there is a workaround until that happens.