"Actix or Tokio runtime not found" error

help
1

I am trying out a sample code from a portal to build REST API using actix-web. It compiles fine but when I run this I get the error:

thread 'main' panicked at 'Actix or Tokio runtime not found; halting', C:\Users\myuserid\.cargo\registry\src\github.com-1ecc6299db9ec823\actix-server-2.3.0\src\server.rs:198:27

Here is the full code from two files, i.e. main.rs and handlers.rs.

// src/main.rs
use actix_web::{web, App, HttpServer};

#[macro_use]

// module declaration here
mod handlers;

#[actix_rt::main]
async fn main() -> std::io::Result<()> {        
    std::env::set_var("RUST_LOG", "actix_web=debug");
    dotenv::dotenv().ok();

    // Start http server
    HttpServer::new(move || {
        App::new()
            .route("/users", web::get().to(handlers::get_users))
            .route("/users/{id}", web::get().to(handlers::get_user_by_id))
            .route("/users", web::post().to(handlers::add_user))
            .route("/users/{id}", web::delete().to(handlers::delete_user))
    })
    .bind("127.0.0.1:8000")?
    .run()
    .await
}

// src/handlers.rs
use actix_web::Responder;

pub async fn get_users() -> impl Responder {
    format!("hello from get users")
}

pub async fn get_user_by_id() -> impl Responder {
    format!("hello from get users by id")
}

pub async fn add_user() -> impl Responder {
    format!("hello from add user")
}

pub async fn delete_user() -> impl Responder {
    format!("hello from delete user")
}

I am new to Rust. Not sure why I get this error. I tried adding tokio to Cargo.toml and also tried adding use actix_rt::Runtime; to top of the main.rs but it didn’t help.

TIA

2

I just ran the code on Windows with the following Cargo.toml, and it works fine here:

[package]
name = "actix-rest-api"
version = "0.1.0"
edition = "2021"

[dependencies]
actix-rt = "2.9.0"
actix-web = "4.5.1"
dotenv = "0.15.0"

Ran it with cargo run and in another terminal tested with:

$ curl -v http://127.0.0.1:8000/users
*   Trying 127.0.0.1:8000...
* Connected to 127.0.0.1 (127.0.0.1) port 8000
> GET /users HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-length: 20
< content-type: text/plain; charset=utf-8
< date: Fri, 05 Apr 2024 01:32:15 GMT
<
hello from get users* Connection #0 to host 127.0.0.1 left intact
3

Yes, it compiled for me too. Thanks a lot for your help. The primary difference was use of older version of actix-rt in my Cargo.toml which I copied from the two year old article.

actix-rt = "1.0.0"  => should be 2.9.0

The actix-web version was also old but I found and updated it to latest. Missed this.

4

By the way, actix-web re-exports the main macro (as actix_web::main) and the relevant types from actix-rt (in the actix_web::rt module). If you use those you can remove actix-rt from your Cargo.toml and you won't have to care about continuously updating actix-rt to the correct version for your actix-web.

3 Likes
5

Thanks for sharing that info @SkiFire13. I am still trying to grasp this. I and a colleague found another example code about four months back for building REST API. It was old, we could change a few lines and get it to compile and work but the moment we touched the dependencies it used to stop compiling. We tried hard but couldn't get it to work. It was compiling but not running on Windows but running on Linux. We have been facing all these kinds of challenges.

I want to know, if it is ok to use the latest version of each package for any application. I don't know how Rust handles a situation like this, hypothetical question:

An application depends on packages A, B, X & Y.
Package A depends on 0.5.0 of X
Package B depends on 0.7.0 of X

How does Rust manage the compilation if 0.5.0 and 0.7.0 are incompatible. Will it use both of them? Or does it store & use only one version of one package in the build directory?

Still trying to understand these intricacies.

6

Cargo considers them to be different major versions, in which case it will include both and treat them as if they were different crates.

7

In addition, types included from different major versions of a crate will be considered completely different types, and therefore incompatible. This is a common cause of weird compiler errors in the form "Expected Foo but found Foo".

1 Like
8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.