@PhilETaylor Sure that is the solution? When I add a error_log((string) $sessionId); just before the changed line and have session handler set to filesystem so I can reproduce the problem, I get in the error log: Resource id #386.

With the code change I had proposed in the issue, I did get the correct session ID in the log.

Well it doesn't cause that type error. But does it really destroy the session?

With my code, the guest session was removed after login, with the code proposed here it isn't.

Update: I mean the session records in database when collection session metadata is switched on and the session handler is file system.

I think this PR does not work. See https://www.php.net/manual/en/language.types.string.php#language.types.string.casting

Resources are always converted to strings with the structure "Resource id #1", where 1 is the resource number assigned to the resource by PHP at runtime. While the exact structure of this string should not be relied on and is subject to change, it will always be unique for a given resource within the lifetime of a script being executed (ie a Web request or CLI process) and won't be reused

So from what I see, you don't see the PHP error because the code successfully convert the data to string, however, it return wrong Session ID as you can guess.

After some Google Search, I think we might have to accept the ugly code #33740 (comment) and move on.

@PhilETaylor We cast stuff (e.g. objects) to strings here and there, but on a quick search yesterday I haven't found any place where we do that for resources. If you find such a place, please report it with a new issue because that would be a bug, as far as I understand PHP docs.

Alternative PR see #33819 .

Can you update the title please. We should use tags to indicate release blocker