When I use loco, the following error is too common. what reason? #586

Allin2000 · 2024-04-30T06:33:16Z

Allin2000
Apr 30, 2024

#![allow(clippy::unused_async)]
use loco_rs::prelude::*;
use sea_orm::DeleteResult;
use crate::models::_entities::recipes;
use crate::models::_entities::recipes::{ActiveModel};

use serde::Deserialize;
use axum::response::Json;
use axum::extract::Query;
use axum::extract::Path;
use serde::Serialize;

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct RecipeSearchParams {
pub limit: i32,
}

#[derive(Clone, Debug, Serialize, Deserialize)]
pub struct RecipeCreate {
pub label: Option,
pub source:Option,
pub url: Option,
}

impl RecipeCreate {
fn update(&self, item: &mut ActiveModel) {
item.label = Set(self.label.clone());
item.source = Set(self.source.clone());
item.url = Set(self.url.clone());
}
}

pub async fn fetch_receipe(Path(id): Path, State(ctx): State) -> Result{
let result = recipes::Entity::find_by_id(id).one(&ctx.db).await?;

Ok(format::json(result)?)

}

pub async fn remove_recipe(Path(id): Path, State(ctx): State) -> Result {
// Delete the recipe from the database
let res: DeleteResult = recipes::Entity::delete_by_id(id).exec(&ctx.db).await?;

// Check if any rows were affected by the delete operation
if res.rows_affected == 0 {
    // No rows were affected, so the recipe was not found in the database
    return Err(eyre::eyre!("Recipe not found").into());
}

format::empty()

}

pub async fn search_recipes(Query(params): Query, State(ctx): State) -> Result {
let all_results = recipes::Entity::find().all(&ctx.db).await?;
let result :Vecrecipes::Model= all_results.into_iter().take(params.limit as usize).collect();
Ok(format::json(result)?)
}

pub async fn create_recipe(Json(params): Json, State(ctx): State) ->Result{

let mut active_model = ActiveModel {
    ..Default::default()
};
params.update(&mut active_model);
let res = active_model.insert(&ctx.db).await?;
Ok(format::json(res)?)

}

pub fn routes() -> Routes {
Routes::new()
.prefix("recipes")
.add("/:id", get(fetch_receipe))
.add("/remove_recipe/:id", get(remove_recipe))
.add("/search_recipes", get(search_recipes))
.add("/create_recipe", post(create_recipe))

}

---------------------------------------------------------error

root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp# cargo loco doctor
Compiling myapp v0.1.0 (/root/fastapi-project/fastapi-learn/loco-learn/myapp)
error[E0277]: the trait bound fn(axum::Json<RecipeCreate>, loco_rs::prelude::State<loco_rs::prelude::AppContext>) -> impl std::future::Future<Output = std::result::Result<axum::http::Response<Body>, loco_rs::Error>> {create_recipe}: Handler<_, _> is not satisfied
--> src/controllers/recipes.rs:82:37
|
82 | .add("/create_recipe", post(create_recipe))
| ---- ^^^^^^^^^^^^^ the trait Handler<_, _> is not implemented for fn item fn(Json<RecipeCreate>, State<AppContext>) -> impl Future<Output = Result<Response<Body>, Error>> {create_recipe}
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait Handler<T, S>:
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1
|
389 | top_level_handler_fn!(post, POST);
| ^^^^^^^^^^^^^^^^^^^^^^----^^^^^^^
| | |
| | required by a bound in this function
| required by this bound in post
= note: this error originates in the macro top_level_handler_fn (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try rustc --explain E0277.
error: could not compile myapp (lib) due to 1 previous error
root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp#

Allin2000 · 2024-04-30T06:34:23Z

Allin2000
Apr 30, 2024
Author

root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp# cargo loco doctor
Compiling myapp v0.1.0 (/root/fastapi-project/fastapi-learn/loco-learn/myapp)
error[E0277]: the trait bound fn(axum::Json<RecipeCreate>, loco_rs::prelude::State<loco_rs::prelude::AppContext>) -> impl std::future::Future<Output = std::result::Result<axum::http::Response<Body>, loco_rs::Error>> {create_recipe}: Handler<_, _> is not satisfied
--> src/controllers/recipes.rs:82:37
|
82 | .add("/create_recipe", post(create_recipe))
| ---- ^^^^^^^^^^^^^ the trait Handler<_, _> is not implemented for fn item fn(Json<RecipeCreate>, State<AppContext>) -> impl Future<Output = Result<Response<Body>, Error>> {create_recipe}
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait Handler<T, S>:
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1
|
389 | top_level_handler_fn!(post, POST);
| ^^^^^^^^^^^^^^^^^^^^^^----^^^^^^^
| | |
| | required by a bound in this function
| required by this bound in post
= note: this error originates in the macro top_level_handler_fn (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try rustc --explain E0277.
error: could not compile myapp (lib) due to 1 previous error
root@T14P:~/fastapi-project/fastapi-learn/loco-learn/myapp#

0 replies

Allin2000 · 2024-04-30T07:05:08Z

Allin2000
Apr 30, 2024
Author

correct pub async fn create_recipe(State(ctx): State,Json(params): Json) ->Result
error pub async fn create_recipe(Json(params): Json,State(ctx): State) ->Result
This error is unbelievable！！！！！！！！

0 replies

Muxoid · 2024-04-30T15:38:50Z

Muxoid
Apr 30, 2024

I had the same error and it caused me a lot of confusion I made this pull request to solve it and make the errors more readable.

import this: use axum::debug_handler;

and add this macro to your handler that is causing the issue like so.

#[debug_handler]
pub async fn echo(req_body: String) -> String {
req_body
}

0 replies

Allin2000 · 2024-04-30T15:53:46Z

Allin2000
Apr 30, 2024
Author

documents : Building a CRUD API

pub async fn update( Path(id): Path,State(ctx): State,Json(params): Json) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}

An error is reported when changing the order of function parameters.

pub async fn update( Path(id): Path,Json(params): Json,State(ctx): State) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}

error[E0277]: the trait bound is not satisfied
--> src/controllers/recipes.rs:82:37
|
82 | .add("/create_recipe", post(create_recipe))
| ---- ^^^^^^^^^^^^^ the trait is not implemented for fn item
| |
| required by a bound introduced by this call
|
= help: the following other types implement trait :
<axum_extra::handler::or::Or<L, R, Lt, Rt, S> as Handler<(M, Lt, Rt), S>>
<axum_extra::handler::IntoHandler<H, T, S> as Handler<T, S>>
<Layered<L, H, T, S> as Handler<T, S>>
<MethodRouter as Handler<(), S>>
note: required by a bound in loco_rs::prelude::post
--> /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/axum-0.7.5/src/routing/method_routing.rs:389:1

0 replies

Muxoid · 2024-04-30T16:44:06Z

Muxoid
Apr 30, 2024

Yes, the order matters for the parameters. If you add this macro #[debug_handler] to your function you will get better error messages.

#[debug_handler]
pub async fn update( Path(id): Path,Json(params): Json,State(ctx): State) -> Result {
let item = load_item(&ctx, id).await?;
let mut item = item.into_active_model();
params.update(&mut item);
let item = item.update(&ctx.db).await?;
format::json(item)
}

Like this but do not forget to import the following.

use axum::debug_handler;

0 replies

Allin2000 · 2024-04-30T17:11:57Z

Allin2000
Apr 30, 2024
Author

This design is very unreasonable.Is it possible to make the order of function parameters not affected?
1.documents : Building a CRUD API . function (list ,add,update,remove,get_one) .The order of arguments for these functions in the official documentation is confused.
2.The second is that the misinformation is outrageous.
3. #[debug_handler] I only found out about this plan after talking to you.

0 replies

isaacdonaldson · 2024-05-02T19:26:28Z

isaacdonaldson
May 2, 2024

For what's worth, I don't think the design is "very unreasonable" - like everything, it has tradeoffs. The loco server handlers are actually from a library called axum, and it makes heavy use of macros to make some things easier for developers (some runtime errors become compile time errors). One of the side effects is that the error messages are very unhelpful, which is why they created another macro to give better error reporting. I'll grant you it's not the easiest to discover, but you asked a question and got an answer from the community - seems like an okay exchange to me.

I'm not sure what you mean by "the misinformation is outrageous".

Back to talking about tradeoffs, the axum crate provides "extractors" (I might be misremembering the terminology) that allow developers to pattern match on params passed to the handler. Being able to pattern match on these params is a powerful tool to allows developers to be declarative, instead of having to imperatively do the same thing. But like all HTTP route handlers, they are bound by the same rules; namely, you can't read the body of an HTTP request/response stream more than once (as found in other languages like JavaScript). The order of the params being passed to the handler matters because the order of operations matter (axum order of extractors documentation). If you hate the extractors you can always read the body from the request itself as well, dealers choice (although not as simple).

I don't speak for loco, but it would be quite the undertaking to document all the libraries it uses on top of the loco specific behaviours. I WOULD agree that having a blurb in the documentation about order of extractors mattering, and a link to the respective documentation would be a net benefit.

0 replies

Allin2000 · 2024-05-02T23:47:16Z

Allin2000
May 2, 2024
Author

pub async fn fetch_receipe(Path(id): Path, State(ctx): State) correct
pub async fn fetch_receipe(State(ctx): State，Path(id): Path) correct

but

async fn create_recipe(State(ctx): State,Json(params): Json) correct
async fn create_recipe(Json(params): Json,State(ctx): State) error

That's why it's puzzling.

0 replies

isaacdonaldson · 2024-05-03T01:01:34Z

isaacdonaldson
May 3, 2024

Something subtle that is mentioned in the docs I linked above is the disclaimer that extractors who implement the FromRequest trait HAVE to be last in order, and ones that implement the FromRequestParts trait can be anywhere but last. Another thing mentioned is that no type can implement both FromRequest and FromRequestParts. Since the Json extractor needs to read the body of the request, it can't have any extractor go after it (can only read the body stream once). This means it must implement FromRequest, requiring it to be put last in the order. The State and Path extractors do not read from the body stream and therefore implement the FromRequestParts trait, meaning the order can be switched around as long as none are put after an extractor that implements FromRequest.

In your first example, both State and Path implement FromRequestParts and have no extractors that implement FromRequest, so the order of them can be changed around. But in the second example, Json implements FromRequest (meaning it reads the http request body stream) so it HAS to go last, that's why there is an error when it is not put last.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

When I use loco, the following error is too common. what reason? #586

{{title}}

Replies: 9 comments

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

When I use loco, the following error is too common. what reason? #586

Allin2000 Apr 30, 2024

Replies: 9 comments

Allin2000 Apr 30, 2024 Author

Allin2000 Apr 30, 2024 Author

Muxoid Apr 30, 2024

Allin2000 Apr 30, 2024 Author

Muxoid Apr 30, 2024

Allin2000 Apr 30, 2024 Author

isaacdonaldson May 2, 2024

Allin2000 May 2, 2024 Author

isaacdonaldson May 3, 2024

Allin2000
Apr 30, 2024

Allin2000
Apr 30, 2024
Author

Allin2000
Apr 30, 2024
Author

Muxoid
Apr 30, 2024

Allin2000
Apr 30, 2024
Author

Muxoid
Apr 30, 2024

Allin2000
Apr 30, 2024
Author

isaacdonaldson
May 2, 2024

Allin2000
May 2, 2024
Author

isaacdonaldson
May 3, 2024