"Session handle still has owners"
j0lol opened this issue Ā· comments
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:
Lines 346 to 348 in 4c7480a
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
The issue is with how the async-session
crate implements Clone.
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.
I'm also working on a new direction which addresses this among other things. Please see #56.
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.