HandleErrorLayer without timeout

[BratSinot]

Greetings!

Any way to create custom error -> Response handler without timeout?
This builds fine:

        .layer(
            ServiceBuilder::new()
                .layer(HandleErrorLayer::new(parse_reject))
                .timeout(std::time::Duration::from_secs(30))
        )

this give big template error:

        .layer(
            ServiceBuilder::new()
                .layer(HandleErrorLayer::new(parse_reject))
        )

error[E0277]: the trait bound `axum::error_handling::HandleError<axum::routing::Route<_>, fn(std::boxed::Box<(dyn std::error::Error + std::marker::Send + std::marker::Sync + 'static)>) -> impl std::future::Future<Output = (axum::http::StatusCode, axum::Json<api::ResponseError>)> {api::parse_reject}, _>: tower::Service<axum::http::Request<_>>` is not satisfied
   --> server/src/api/mod.rs:21:10
    |
21  |         .layer(
    |          ^^^^^ the trait `tower::Service<axum::http::Request<_>>` is not implemented for `axum::error_handling::HandleError<axum::routing::Route<_>, fn(std::boxed::Box<(dyn std::error::Error + std::marker::Send + std::marker::Sync + 'static)>) -> impl std::future::Future<Output = (axum::http::StatusCode, axum::Json<api::ResponseError>)> {api::parse_reject}, _>`
    |
    = help: the following other types implement trait `tower::Service<Request>`:
              axum::error_handling::HandleError<S, F, ()>
              axum::error_handling::HandleError<S, F, (T1, T2)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3, T4)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3, T4, T5)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3, T4, T5, T6)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3, T4, T5, T6, T7)>
              axum::error_handling::HandleError<S, F, (T1, T2, T3, T4, T5, T6, T7, T8)>
            and 9 others
note: required by a bound in `axum::Router::<B>::layer`
   --> /Users/asinotov/.cargo/registry/src/github.com-1ecc6299db9ec823/axum-0.5.13/src/routing/mod.rs:297:21
    |
297 |         L::Service: Service<Request<NewReqBody>, Response = Response<NewResBody>, Error = Infallible>
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `axum::Router::<B>::layer`

[jplatte]

Without a layer like the timeout one, there are no errors to handle. Have you read the error handling documentation?

[jplatte]

If you get an error about Handler not being implemented, have a look at debug_handler which helps pinpoint the exact problem.

For customizing rejections from extractors, have a look at the customize-extractor-error example.

[BratSinot]

For customizing rejections from extractors, have a look at the customize-extractor-error example.

I saw that, but implementing your own extract (in my case it ContentLengthLimit and Query) seems strange way for me =)
But ok, at least writing wrappers is better than nothing =)

If you get an error about Handler not being implemented, have a look at debug_handler which helps pinpoint the exact problem.
That working in case, when you use Extension. I use closures.

[davidpdrsn]

You don't "handle" errors in axum. You implement IntoResponse for your error types and they'll automatically be converted into responses and sent the client.

See the error handling example the repo for a demo.

This probably something we can make clearer in the docs. Been getting this question quite often lately.

[BratSinot]

Been getting this question quite often lately.

Because people start using axum =)
And, of course, they want to have one error view.

[davidpdrsn]

And, of course, they want to have one error view.

That's not a given. With axum's model you're guaranteed that all errors are handled appropriately. Warps "recover" systems requires you to remember to handle all possible errors, which inevitably means you'll forget some.

[BratSinot]

For customizing rejections from extractors, have a look at the customize-extractor-error example.

I saw that, but implementing your own extract (in my case it ContentLengthLimit and Query) seems strange way for me =) But ok, at least writing wrappers is better than nothing =)