I have a response to my question about string keys. Since I use the default session store (cookie_store), my session gets serialized as JSON. It seems it does not get restored to the original form when the call returns from the frontend. So that's all right. I've got some other feedback saying that calling reset_session before login might cause the CSRF token to be deleted too and cause the effect I see. However, I don't use reset_session before login (owing to specific reasons). I just delete the relevant info from the session via session.delete('user_id') or similar.

One more bit of information. I don't use Devise. It was there in my project all the time but I never used it. I've since uninstalled it. The error persists. Sigh.

Can you track down logs for the affected requests? There can be something along the lines of "Filter chain halted as ... rendered or redirected" that can serve as a starting point for further investigation.

Yes, there is. That filter chain statement says "redirected to login screen". The redirect happens because the session ist empty in spite of its having been written to before. And I have been logging the session too. It's written to correctly; the puts statement outputs the session in exactly the state I would expect it to be: After authenticating the user the user id is written to the session. The log statement is *** session currently is: {user_id: <value>}***. Then I redirect the user to the start page of the user screen, which redirects because the session suddenly is empty again, the log statement is *** session currently is: {}***. That's all there is; the session is lost. And it happens time and again, occasionally, and in no case it's reproducible. It must be some kind of async problem. Personally, I kind of feel the fact that the "session is written lazily" (as per documentation) is the problem.

Thanks! Yeah, that's weird... Do you call protect_from_forgery on your application controller (just to rule it out, you can set skip_before_action :verify_authenticity_token that should suppress protection)? It's supposed to skip GET & HEAD requests, but it's possibly related given that the default action is to substitute the session with an empty one without failing the request.

Sorry, haven't been around for a while. I meanwhile implemented a parallel session management using the database, that's how frustrated I was. No, I don't call protect_from_forgery on the application controller. I removed that line as I understood it's now included by default in ActionController::Base.