Using aide in an axum app that also utilizes tower_sessions::Session

[PeterGrace]

I apologize if this question is somewhat vague; it comes from the fact that I'm not sure if I'm on the right path.

I'm designing an axum app that will be interacted with by a web front-end and a mobile app. Because of this, I want strong openapi docs to help the implementation of the client side. So far, aide has been great. I also want to implement session handling so that some data can be persisted between calls. For this, I have implemented a middleware to insert a session object into the request extensions.

The problem comes in now where because I have to consume request to get to the session object, I now need to parse the body in my function to resolve the inbound json payload for POSTs. This seems to break how aide handles detecting inputs/outputs, even if I derive OperationIo and use #[aide(input)], etc.

I've been looking for the 'right way' to hint to aide what the proper inputs and outputs are for the routes, but now I'm wondering if I'm even going about this the right way. Some other axum-derived projects instead create a new struct that implements FromRequest and FromRequestParts, and I'm wondering whether I should be doing something like that.

I guess the TL;DR boils down to: "does anyone have a small example of how to use aide for documenting routes while also using tower_sessions Session management?"

[tamasfe]

aide only sees the parameter and the return types of your handlers, nothing else. If you have a fn foo(req: Request), the contents of the request will be opaque to aide and thus won't be able to generate any documentation.

Some other axum-derived projects instead create a new struct that implements FromRequest and FromRequestParts

I'd say that this is the way to do it, so that everyone, including aide immediately sees what the handler needs.

even if I derive OperationIo and use #[aide(input)], etc.

By itself the derive macro only generates an empty implementation so that the type can be used in handlers but you need to manually implement OperationInput for the type to add any meaningful documentation.

[PeterGrace]

as a test before trying to go through FromRequest/FromRequestParts steps, I figured I would attempt to merge the tower_sessions example and the aide example together to see if I could get it working with the normal Sessions method. I'm getting an error however, that I'm not 100% certain how to solve. It seems like aide wants to treat Session like it is an input variable from the api call and wants OperationHandler implemented, but not sure if I can do that? I'm hopeful that you'll be able to solve these issues at a glance, they're likely just me not being 100% familiar with how aide blankets axum. Can you give me some pointers? My guess is if I can resolve these issues then I don't need to mess with FromRequest/FromRequestParts or pull the request in.

The code is in https://github.com/PeterGrace/tmp_axum_test

error[E0277]: the trait bound `fn(tower_sessions::Session) -> impl Future<Output = impl IntoApiResponse> {handler}: OperationHandler<_, _>` is not satisfied
   --> src/main.rs:55:29
    |
55  |         .api_route("/", get(handler))
    |                         --- ^^^^^^^ unsatisfied trait bound
    |                         |
    |                         required by a bound introduced by this call
    |
    = help: the trait `OperationHandler<_, _>` is not implemented for fn item `fn(tower_sessions::Session) -> impl Future<Output = impl IntoApiResponse> {handler}`
    = help: the trait `OperationHandler<I, O>` is implemented for `axum::handler::Layered<L, H, T, S>`
note: required by a bound in `aide::axum::routing::get`
   --> /home/pgrace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/aide-0.14.1/src/axum/routing.rs:345:1
    |
345 | method_router_top_level!(get, get_with);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^---^^^^^^^^^^^
    | |                        |
    | |                        required by a bound in this function
    | required by this bound in `get`
    = note: this error originates in the macro `method_router_top_level` (in Nightly builds, run with -Z macro-backtrace for more info)

[jplatte]

It seems like aide wants to treat Session like it is an input variable from the api call and wants OperationHandler implemented, but not sure if I can do that?

Indeed, and you can't do that, at least not without changing upstream ans making either aide depend (optionally) on tower-sessions, or the other way around.

[PeterGrace]

I'm trying to think through this as a consumer of aide and I'm wondering if it's weird to want to have session support in an api I also want documented via OpenAPI. Is the pattern of adding an argument to the handler somewhat unusual? The reason I'm consuming the request in the first place is to get access to req.extensions() inside the handler -- I'm trying to have my cake and eat it too since I'm not sure if I understand how to implement this in a FromRequest/FromRequestParts scenario.

To restate the above stream-of-conscious more clearly: "What is the 'right way' to implement aide and tower_sessions Session support? If it's FromRequest or FromRequestParts implementation, any hints/pseudocode on how that would solve the issue?