"Session handle still has owners"

[j0lol]

I was trying to use axum-sessions within the leptos framework and I encountered an error where leptos seemed like it would not drop AuthContext. I reported it to leptos and it seems like it is an issue with your middleware: https://github.com/maxcountryman/axum-sessions/blob/4c7480a205953abbc89bbef56391af2ac94533af/src/session.rs#L346-L348

Why does this type implement Clone and then panic if it is cloned and used? Why is this not documented? Surely this edge case can be worked around, or at least pushed to a compile-time error?

If you would like to see the issue, this project errors with this reproducibly here

[maxcountryman]

The issue is with how the async-session crate implements Clone.

[maxcountryman]

It looks like v4 of async-session will allow us to clone the Session directly. This should mean we can drop the lock altogether. As soon as that lands, I'm planning to remove the custom extractor and lock.

[maxcountryman]

@j0lol there's active work in #50 to address.

[maxcountryman]

I'm also working on a new direction which addresses this among other things. Please see https://github.com/maxcountryman/axum-sessions/discussions/56.

[maxcountryman]

I've released v0.1.0 of tower-sessions for folks who would like to try that.

This new crate does not use async-session and takes an approach to managing inner state that's inline with other tower middleware, like tower-cookies.

If you end up trying it, please let me know how it goes.