-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The kernel reboot #130
Comments
@Legion112 could you please send a PR for this? It would also help to have a test in our test project ( Codeception/symfony-module-tests ) with which we verify that your change solves the issue (and that it will not be damaged in future versions). Please follow the contribution guide ( master/CONTRIBUTING.md ), and if all goes well I will gladly merge the changes. |
Hello! I also would like to notice that way this module is reboot Symfony Kernel differ from way doing that in Symfony KernelTestCase. Looks like this leads to services which implements Symfony\Contracts\Service\ResetInterface are not reset. Look at symfony/symfony#40965 for example. |
@Legion112 @TavoNiievez is there any progress on this issue? Thanks! |
Sorry no longer work with codeception. We used static variables for setting the state of stub classes. |
I think the process of rebooting the kernel should be done right after the request has been finished.
Here we have logic that will reboot the kernel only when a second request is made.
https://github.com/Codeception/module-symfony/blob/master/src/Codeception/Lib/Connector/Symfony.php#L63
I think we should change it to:
Why is it important?
If the kernel is rebooted only when a second request happened - we cannot configure the "DI" container on the fly. Like setting Stubs classes.
Something like this:
The text was updated successfully, but these errors were encountered: