worker: add test on lazy session save path

[xavierleune]

This small reproducer should reproduce the issue #2185

This bug has probably be introduced with the PR #2139: we now reset ini settings between requests and symfony sets the save_path only on the first use of the session object.

We have a few possible ways to fix it here:

1. Rollback the ini reset, that would reintroduce some bugs
2. Exclude session settings from reset, that might do the trick but is fragile
3. Propose a fix on symfony to make sure ini_set are always called

I went through all the symfony code base, we have the following ini_set:

• A lot in the cache component but all settings are rolled back after (like: $unserializeCallbackHandler = ini_set('unserialize_callback_func', __CLASS__.'::handleUnserializeCallback'); /* do stuff */ ini_set('unserialize_callback_func', $unserializeCallbackHandler);)
• Error Handler: in method enable: not normally used in worker mode
• HttpFoundation\Response this should not have been persisted between requests
• Session:
  • NativeSessionStorage all options are set by construct only
  • NativeFileSessionHandler - save_path and save_handler
• Symfony\Component\Messenger\Transport\Serialization\PhpSerializer same pattern than cache: set + rollback after unserialize
• Firewall: same pattern
• Runtime: BasicErrorHandler and SymfonyErrorHandler: the error handler is registered in construct of the GenericRuntime

@dunglas @AlliBalliBaba @henderkes WDYT ?

[henderkes]

I've tried this out, but it turns out that none of the ini_set directives you had mentioned are even getting hit.

[xavierleune]

@henderkes not sure what you meant, I've tried with a real sf 8 app and the bug came from the ini_set('session.save_path'). If I revert the changes around ini, tests are green. Sorry I feel like I'm missing the point here, may you be more specific ?

[henderkes]

I've tried debugging a demo application with handler_id: ~ and it's never even constructed nor hit. I'm not sure how to reproduce the issue is what I'm saying and therefore I'm not sure if it fixes it.

[xavierleune]

I used the following config, the path comes from the issue

    session:
        handler_id: null
        cookie_secure: false
        save_path: '%kernel.project_dir%/var/sessions/%kernel.environment%'

[henderkes]

save_path: '%kernel.project_dir%/var/sessions/%kernel.environment%'

That explains it, there's conditional logic prior if the path is different.

However, since it was never hitting these code paths for me and I still ran into issues, that cannot be the whole store. There's got to be a bug somewhere unrelated to the ini settings as well.

[dunglas]

I'm in favor of reverting the INI stuff entirely and documenting explicitly about what is reset and what isn't.

INI settings are not request-bound, so there is no reason to reset them.

If Symfony does stuff like this, it's entirely sure that many existing apps also do it.

[xavierleune]

@henderkes defaut in symfony is %kernel.cache_dir%/sessions so if that's not the default value in your php.ini the code path should have been triggered

[AlliBalliBaba]

I think a potential failure could also come from not being able to reset an ini setting at the end of a request (for various reasons). So yeah, the safe bet would be to just not reset them and document the behavior.

We also don't reset global variables in general, so probably makes sense to count ini settings to global variables.