[sfried]

Problem

handler::runner's memory sweep awaits store_session inside a DashMap iterator:

for session in session_store.inner.iter().filter(|r| r.autoremove < current_time) {
    if !session.expired() {
        if let Err(err) = session_store.store_session(&session).await {

The iterator holds the current shard's read lock across the database write. While that future is suspended, a request whose session id hashes to the same shard reaches SessionService, which calls inner.insert / get_mut / remove (service.rs) — a synchronous write lock on that shard — and blocks its tokio worker thread. If that worker is the one driving the I/O reactor, the database write the sweep is waiting on can never complete, the read lock is never released, and the whole server stops: 0% CPU, every thread parked in a futex, the listen backlog growing, database connections idle.

We hit this three times under sustained test traffic (many logins, so many in-memory sessions become due for unloading while requests keep arriving) on 0.21/0.22 with axum_session_sqlx. A core dump showed one runtime worker in dashmap::lock::RawRwLock::lock_exclusive_slow under the SessionService future and every other worker parked.

Fix

The sweep's save step moves into save_due_sessions, which clones the due, unexpired sessions out of the map first and awaits each store_session after the iterator is dropped. The filter, the stop-at-first-error behaviour and the debug logs are unchanged.

Test

handler::tests::save_due_sessions_does_not_hold_a_shard_lock_across_the_store_await runs the save step on a one-worker multi-thread runtime with a slow DatabasePool (its store awaits a timer), while a second task writes the very session being saved; a watchdog on a separate std thread turns a hang into a failure. With the old loop it times out (5 s); with the fix it passes in ~0.2 s.

cargo fmt --check is clean; cargo clippy -p axum_session --features key-store --all-targets reports only the existing aes_gcm deprecation warnings.

Unrelated, noticed while testing: on current main, --features advanced doesn't compile (Utc is not in scope at session_store.rs:523,539).

🤖 Generated with Claude Code

[genusistimelord]

Very good find. The aes_gcm issue is more of idk how to do a similar style with the newer changes yet. I don't want to enforce a database sweep if the changes break all the encrypted sessions.