Hello,

yesterday a blog post was published announcing that the session service would be deprecated in 5.3 and removed in 6.0. While I agree that the current approach is problematic for the reasons explained in the blog post, I believe that the change introduced in #38616 does not go in the way of actually fixing the problem and simply swaps one mistake for another.

The main issues we have currently are:

1. The session is currently treated as a data object and as a service which lives in the service container. As a general rule of thumb, I think we can agree that things that live in the service container should be stateless (except maybe a few very specific use cases), and a data object is definitely not stateless.
2. The session handling is part of the HTTP foundation, which is wrong because sessions are not a part of the HTTP specification. Having this code live in the HTTP foundation is a byproduct of how PHP sessions are handled, with (put simply) a request cookie used to identify the backend session.

The change in #38616 fixes none of these issues. We no longer require SessionInterface but we require RequestStack, which is also a stateful data object from the HTTP foundation. In there we have a getSession shortcut which takes the last request (even though from a conceptual point of view all the RequestStack sub-requests should share the same session, unless I'm missing something in how this is handled?) and returns the session from that. With this, we keep Request (and therefore the HTTP foundation) session-aware, and we also spread the "session-awareness" to RequestStack, too.

For this reasons I believe the current approach is less than ideal, as it introduces a deprecation which does not fix the actual issues in meaningful way, and also spreads the "session-awareness" to other points of the HTTP foundation. My suggestion would be to revert the PR before 5.3, so we avoid publishing and encouraging some behavior which will need to be changed anyway (leading to users having to change their code twice), and use this issue to start the discussion of what the read fix would be, that is, moving the session management part to a separate component (something which has been talked about in the past). Of course, because 5.3 is coming up fast, this new fix would have to be postponed to 5.4/6.0.

Needless to say, I would be super happy to help with this.

@fabpot @javiereguiluz tagging both of you as you replied to my comment on the blog post saying we should move the discussion here.

Cheers!