A `destroy`ed session is still `touch`ed

[luxaritas]

The check for whether a session should be touched just checks whether the session ID is the same as at the beginning of the request. Calling destroy does not change the session ID but only removes the session object and calls destroy on the store. Since the session has been removed from the underlying store and touch intends to update an existing session in the store.

A workaround is to call regenerate instead of destroy, which also changes the session ID (and causes a new session to be saved, avoiding the old session from being updated)

[luxaritas]

On further review, this didn't pan out to be what is happening. There is an early bail before save/touch if there is no session object. What I was seeing in my monitoring was a race condition where a regular request and a logout request would be sent concurrently and the destroy happened before the end of the regular request, so the regular request still provided the old session info which didn't exist. My bad!