You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
however, into_response() does not have access to state or other extractors, and most importantly for me cannot be async: the "frame" part of the error page has become dynamic and requires an await to get a tokio read lock. I never expect this to be slow or deadlock so I could use a std lock instead, but this really looks exactly like the error_handling module is about... Except that I've just spent a full day trying to get it working and haven't been able to please the type checker whatever I do.
What I tried:
ideally most of my routes can return an error, so my first attempt was (to drop the intoResponse on the error and) adding a .layer(HandleErrorLayer::new(myhandler)) to my main router, to no avail.
I've also tried sugarcoating each routing::get(handler).handle_error(myhandler) without more luck
I've considered wrapping routing::get to grab the handler and return a super-handler that is infallible, but after much flailing around I realized that'd mean doing something like the impl_handler / impl_handler_call_with in src/handler/mod.rs but my time ran out before I could sort out the types and I ran out of time; I'm giving up on pretty pages on error for now.
imagine the same with a couple dozen of .route(), stuff actually failing, and now the actual error template wanting some data obtained from async... I also had some state extracted but it's not strictly required in this case, so didn't include it in repro.
(Sorry, it's all going to be open source so you'll be able to see how bad it is in a few weeks, but company policy is not publish early...)
So to recap the question: what would you suggest to get async in the error path?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello, thanks for axum!
I've been trying to print a nice error page on my project which has a lot of failure patterns.
My first approach was defining IntoResponse on my error type, I found out about this project later but basically exactly like this (except I use anyhow, but that's irrelevant):
https://github.com/knarkzel/axum-error/blob/master/src/lib.rs
however,
into_response()
does not have access to state or other extractors, and most importantly for me cannot be async: the "frame" part of the error page has become dynamic and requires an await to get a tokio read lock. I never expect this to be slow or deadlock so I could use a std lock instead, but this really looks exactly like the error_handling module is about... Except that I've just spent a full day trying to get it working and haven't been able to please the type checker whatever I do.What I tried:
.layer(HandleErrorLayer::new(myhandler))
to my main router, to no avail.routing::get(handler).handle_error(myhandler)
without more luckimpl_handler
/impl_handler_call_with
in src/handler/mod.rs but my time ran out before I could sort out the types and I ran out of time; I'm giving up on pretty pages on error for now.Here's a minimal reproducer of what our code is currently doing:
https://github.com/martinetd/axum_error_repro
imagine the same with a couple dozen of .route(), stuff actually failing, and now the actual error template wanting some data obtained from async... I also had some state extracted but it's not strictly required in this case, so didn't include it in repro.
(Sorry, it's all going to be open source so you'll be able to see how bad it is in a few weeks, but company policy is not publish early...)
So to recap the question: what would you suggest to get async in the error path?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions