Hi!

I'm not sure about this change, as it favors session over session.factory. IIRC, we deprecated the session service in 5.3. This means that this change causes an unfixable deprecation notice, and this doesn't fix the situation in 6.0. I guess that's the reason for the original order of this if statement?

I guess it's worth investigating and trying out @stof's proposal in #43266 (comment) . Is anyone up to trying it out? Or let me know if my thinking is completely wrong about this :)

@wouterj FYI, we use $this->client->disableReboot(); so no rebooting is occuring, so I don't think @stof's proposal is completely sound.

@wouterj on a high level I do not even understand why original change breaks something

• new session is created with or without factory
• token is set successfully with or without factory
• first time around everything works "as before" with either option
• second time around first two points are still true, but later authentication somehow breaks

If I understood your and stof's suggestions correctly I'm supposed to make some intermediate $client->request() to force it to reboot before doing $client->loginUser()? Seems like pretty unstable and "boilerplaty" workaround. And it does not work really:

• option with shutdown/boot
• option with extra empty request

The issue happens because the reboot is occurring at the beginning of request() if we need a reboot. And so, the loginUser is done for the old kernel env rather than the new one, while it is meant to be associated to the future request.

What we need is to make loginUser also check for this "needs reboot" state, and perform the reboot itself (then marking the kernel as not needing reboot anymore as it is done).
There is no intermediate request() calls to do (which would not solve the issue anyway, as the we would also reboot between the second request and the third one)

Ok. thanks @stof now I get this high level "overview of a problem.

So basically it is unsolvable from client side for now.

Then, just out of curiosity. Why "old way" with session instead of session.factory works anyway? (even when the logic seems wrong after your explanation)

@stof as i said above, we are NOT rebooting ($this->client->disableReboot();). am I misunderstanding your reasoning?

This can be worked around by changing (the recipe defaults) from:

when@test:
    framework:
        test: true
        session:
            storage_factory_id: session.storage.factory.mock_file

to

when@test:
    framework:
        test: true
        session:
            storage_factory_id: ~
            storage_id: session.storage.mock_file

I don't know why yet.

So after some debugging, the statefull issue is indeed not caused by the kernel rebooting, but instead on unexpected behavior when parsing the response cookies. See #44565 for a fix.

I didn't figure out how to fix stateless firewalls, if anyone wants to try debugging that it would be great.

confirmed #44565 fixes the issue. can be closed here